Trulia.com Full Width Map and Full Size Images

So it seems like Trulia doesn’t respond well to user feedback. They shrunk their images and added that house list that simply hides the awesome map feature we all loved in the past, and the awful image swipe effect that makes me dizzy! No worries, I found a Chrome Extension that fixes their site.

Introducing Stylebot
https://chrome.google.com/webstore/detail/stylebot/oiaejidbmkiecgbjeifoejpgmdaleoha?hl=en

It’s called Stylebot, and it’s made a world of difference for me. After installing it, open it up, go to edit the CSS and paste the following in there.

(minor updates to work with every browser)

.mediaCarouselSwipe {
 height: 100%;
 width: 100%;
}

.mediaCarouselSlides {
 height: 100%;
}

.mediaCarouselSlide.left, .mediaCarouselSlide.center, .mediaCarouselSlide.right {
 width: 100%;
 height: 100%;
 position: absolute;
 bottom: 0;
}

.mediaCarouselImage {
 height: 100%;
 width: 100%;
}

.mediaCarouselSlide {
 transition: transform 0s;
}

.propertyLocalInfoContainer > div > .tabList {
 display: none;
}

.mediaCarouselMediaCounter {
 display: none;
}

.beingModal {
 height: 97%;
}

.titleBar {
 height: 0px;
}

.titleBar ul.section .mhm.linkTypeReversed {
 position: fixed;
 top: 0;
 right: 0;
}

#leftColumn {
 display: none;
}

.hpRtContain {
 display: none;
}

#heroContainer {
 width: 100%;
}

#searchOverlay .banner .box-holder {
 width: 50%;
 margin-left: 25%;
}

 

 

Package Managers and why I hate them: npm or composer

Package Managers Just Suck

They suck big time. Let me tell you how I arrived at that conclusion. First off, theoretically, package managers sound amazing. The idea of running one command sand have everything magically created for you, updated for you, compiled, without too much sweating, is truly a marvel.

package managers suck

Sure, package entire servers when you can simply run a couple of git / svn commands.

In reality, however, this is sadly not the case. Every freakin’ time I try to go back to npm to install something, either for a cordova app, or a Laravel install, or just some custom dependency, I start off following some instruction manual. npm install this, npm install that, and on I go. Until I get to a package that requires something else.

This happens every time. Documentation is very unclear most of the time. Sometimes I have to run npm install with a -g flag, somtimes –save-dev, all sort of options. And Make sure you always have the latest version of npm, unless their site is down, which happens every hour on the hour, or it’s slow, or non responsive, etc.

Communism is the Perfect Form of Government

Just like communism, package managers packatoo shall fail. Not today, not tomorrow, but one day when developers figure out that they can do installs simply by downloading libraries or git/svn-ing them to their development environments.

Just as an example, this one project, I had to install about 30 packages, but that wasn’t enough. There were dependencies like .Net framework, and python, ruby, etc. All for a one page website. Who are these idiots developing websites and making them so complicated? It’s a one page website that could have simply ran off of a simple CMS like WordPress if you really needed a CMS. It was insane.

Ah, Magento Probably Sucks Worse

It was like my old days of when I worked on a one page Magento Sucks project. What a waste. One page just to store addresses of people wishing to win an iPad, with a gigantic, full Magento install in the backend. Ridiculous!

The Dependencies

I honestly thought the whole idea of writing code is to be less dependent on crap and architect something that can easily be modified by others, pick up, learn and hit the ground running. Instead, we find that most developers who enter a new environment these days, have to re-learn a whole new flavor of development. Everything to learning a new server (nginx), backend (node), database (postgress and express), and even front end (sass, less, angular), and there are a bunch more that I haven’t listed, but they’re there. And all for what? There’s no gain in any of it. It’s all how you use the tools at hand. Nginx can be much slower than apache if not configured right, and it’s much more limited in what it can do. Same with Angular and everything else in between.

Why stick with systems that are broken? Use things that were tested over the years and can be more dependable. Things that have a much larger community.

Capistrano is useless: not as good as SVN or Git

Once again, something comes out to “revolutionize” the way things are done. I suppose when Git came out, everyone was going to jump off of the SVN boat. In reality, SVN works just as good as Git. It’s always about how you use the tool. My argument is this: Can you mess up a Capistrano release? Just as much as you can anything else. It’s all about how you do it, not necessarily what tool you use. Not to mention that it’s a Ruby Gem. So if you’re a PHP guy, you’re screwed. Gotta install a bunch more stuff on your server just to make it work. Bollocks!

If it ain’t broke, don’t fix it

So, if a company has been using SVN for years and years, why would they “need” to switch to Git, or Capistrano? I would hope that a company that’s been using SVN for 5 years, would have figured out by now how they’re using SVN. In fact, one of my old work places used SVN brilliantly.

The solution

What they did was this: They had sandboxes for devs, each set up with their own virtual box. Dev environment is complete. They would spin off individual features branches and a sprint branch at the beginning of each sprint. Done. Good so far. At the end of the sprint, they would test on their dev boxes, get business approval, and merge to the sprint branch.

Regression testing

The sprint branch would be pulled down on the qa server, and tested. Two other devs would test the original dev’s story. It took a day, and we didn’t need QA. Once the qa dev (sprint) got approval… no, we would not release to live. In fact, at this point, the lead dev would create a tag. This tag would become the snapshot for the release.

The live server

The tag would be pulled into the live server. Let me explain how the live server was set up. The vhosts had two servers set up. One was a pre-live environment, and one would be a live environment. Both of these had symlinks that pointed to previously created tags. This way you can have the code tested on the live server, using the live database, without affecting the live site code.

Update: Here’s sample bash script ./tag_www

#!/bin/bash
echo "Tag: "
read thetag
echo "Tagging $thetag"
ln -sfn $thetag www
echo "Done!"

And you would just need to run:

# bash tage_www
Tag: tag2

And you’re done

Capistrano is essentially useless

Now that we have symlinks point to different releases, and we know that we can roll back by swapping the symlink to a previous tag, and the only scripts we need are Git’s (SVN’s) commands, why exactly do we need Capistrano as an abstract layer of complication? We don’t. But, because it’s a new tool that sounds cool, your CTO who may not understand how a light switch works, may decide to go with it anyway.

Git vs SVN

So, now, that we realized the Capistrano is a useless piece of software, even though evangelists may swear that it’s better (they’re probably just too lazy to do the actual work required), it really comes down to a personal flavor. Are you used to SVN? Use SVN. Are you used to Git? Use Git. It’s that simple.

What about the scripts?

I, personally, would rather write my own scripts. I know what goes in them, I know I tested them myself, and they don’t require additional software to run. Git and SVN come with their own pre hooks and post hooks. Use the tools at hand. To me, if someone tells me that they want to use Capistrano, it tells me that they don’t know Git or SVN all that well. And to use a new tool with services that they don’t understand is ever scarier.

The shortest road is the one best known

In reality, it comes down to what you know best. But, if you don’t know SVN or Git and are using tools and scripts on a higher level, it’s like saying that you can run a marathon at the age of 50 because you did a 1k when you were 18 years old. it’s like using Zend before you pick up PHP. You’ll have a heck of a time, let me tell you. Learn the basics. If you truly learn the basics of Git, SVN, or any other similar repository, you’ll understand why you’ll never need to use Capistrano.

Don’t be afraid

You might be saying to yourself… “But, I learned Capistrano, why do I need to learn anything else?” Simply because it’s valuable. You’ll be a better developer for doing so. You’ll have a better grasp of deployment and the hows and the whys. Don’t be afraid to master the tools at hand.

What about the database?

There’s a nice UI tool that I personally use. It’s called SLQYog. For about $100 you can get yourself the SQLYog Enterprise or Ultimate which includes some much needed features, such as schema sync, data sync, SSH tunneling, and many more features. Why would you let PHP handle database syncing? I’m talking to you Laravel, and your promise to make database syncing easier with your eloquent. It’s silly to think that PHP can manage your DB. Use smarter tools, don’t be stubborn and don’t fight PHP please.

Do a schema sync before every release. You typically won’t be erasing fields, so you won’t have to worry about that problem. Very rare issue to have. So, changes are that your code will only break when you rename things or remove fields. But, for those times that you do make those exceptions, this tool will be a life saver.

Best practice for when renaming fields, don’t just rename. Add a new field, copy the data, release code, next sprint remove the previous field and done.

More control

In the end, you’ll gain much more control over deployment processes. You’ll understand what’s being pulled / pushed on what server, and you’ll be much more confident running your own scripts. Running a tool that was designed by someone else comes with its own caveats. Just be careful of others’ work. Just like composer, don’t get me started. Basically, if the main install file for composer somehow runs a command to delete your files, there’s no coming back. So much complexity for so little gained.

And remember, always K. I. S. S. (Keep it short and simple).

Want to add image to linkedin app, but don’t have https

Well now, haven’t we all been super excited about creating social logins and such, especially with HybridAuth’s awesomeness.

So, you build out your app, your URLs, callbacks, implement the library, and when you try to set up the app, BAM! Your logo has to have an HTTPS protocol. Rats.

No worries, simplicity to the rescue. All you need is a Dropbox account. No, really, Dropbox. The file sharing account.

* Signup for Dropbox. It’s free, if you don’t already have an account.
* Create a public folder.
* Add your logo to the public folder.
* On your PC, or Mac, or within the app, copy the public link. Right click the image and select “Copy public link”.
* Take the copied link and paste it in your linkedin image field.
* Done!

I hope this helps you guys out as much as it helped me. This comes in handy if you don’t feel like making the trip to ssl land, or are developing locally, but need to use the linkedin app.

Cheers!

Are PHP Frameworks All Hype?

The short answer is, yes.

Let’s explore why that is.

Who in their right mind would try to sell their framework idea by saying, “It’s slower than straight php”, or “it lacks form customization”? I’m pretty sure no one would. This article is based solely on my own personal experience of dealing with web development for over 13 years.

I want to start out by saying that I’ve tried many PHP frameworks. I’ve tried Cake, Magento (a CMS loosely based on Zend philosophy), Symfony2, Zend2, Yii, Codeigniter, Light VC, Laravel, and many other in my own personal time). One thing to note is the amount of frameworks that exist out there just for PHP alone. Why so many? If any one of them were as good as PHP itself, why hasn’t it become the standard? The reason may shock you… or not. PHP frameworks suck! Even Rasmus Leerdorf himself (the creator of PHP) had said it.

Web development and web application development is not the same as any other type of programming. It’s development that creates short lived web pages (applications) and rapid AJAX calls in order to provide the end user with some sort of interaction and/or data management. These little pages, together create the illusion of being “logged in” an application. Applications keep massive amounts of data alive until that application is shut off. Think of the OS that you’re on right now. TONS of things happening in RAM while you’re listening to your favorite music and reading this post. On this particular website, the page has already loaded. Nothing much else is happening. The web app finished rendering a long time ago and is now in a sort of an “off” state. I just want to make sure we understand the differences between web app development and any other type of application development where the data stays alive for the entire duration of the application.

Yes, there are exceptions, such as sockets, but for the most part, most websites render out, and boom, done! The server on the other hand may keep a session alive. If not, your authentication is probably handled by cookies, or RESTful api keys and secrets. Anyway.

Trying to introduce a concept of MVC, previously only used in single language environments (i.e. Java), to a multi language environment (Apache, PHP, MySQL, HTML, CSS, JS, etc) is plain ridiculous. I understand the idea behind separating code, but for a website, it’s ludicrous to think that you can do all of data collection through PHP, or all of the JS calls from PHP, or even CSS rendering from PHP. Websites are a special type of applications that can, and should handle multiple types of languages in order to provide the best experience for end users, visually, and functionally. Imagine if we could only code websites in PHP alone. What a mess that would be.

The simple truth, and this may hurt anyone out there, is that with all of these different frameworks, not one has stood the test of time over a two year period. Everytime PHP gets updated, your frameworks becomes useless. All the bells and whistles just became obsolete. And forget about v2.0 of the framework since nothing is backwards compatible. It’s a complete nightmare.

I always hear the argument about how noobs pick up a framework faster. Faster than what? PHP? Don’t they have to learn PHP first? And if they know PHP, why learn another layer on top? What if you had to hire new developers? You’d have to teach them the framework, and look back at how long it took you to become an expert in the framework, not learn it, but become an expert. Why an expert? Because you made a lot of mistakes while you were learning it, and you can’t afford that with noobs.

Build your PHP code to make sense, and the same goes for code as it does for UI. If it takes more than 3 clicks to get somewhere, it’s probably too complicated. And you know what? No one is going to want to work on that project. Sure, you can hire a framework or CMS specialist and pay them twice as much… but why do all that when you can get two developers for that same price with a simpler system in place? Response / request. That’s it. That’s what the browser understands. Built it that way, and stop calling everything an application as if you were building something in JAVA. Focus on architecture, not frameworks.

The shortest path is one best known. And surprisingly, most php developers know php.

Toggle Functionality for Clean PHP

Requirements:
* jQuery
* Font Awesome
* AJAX capabilities
* .hidden = display: none;

So, I decided that just controlling the front end via the back end wasn’t enough. I debated for a long time and was reluctant to add new functionality to the ajax controller… then I realized that I’m using a lot more of this functionality, so, I caved in.

This complements the ajax functionality by adding a toggle feature for either items that toggle out (2 state on/off), or items that toggle other elements on or off; still 2 state.

The first thing I did was to add some classes to the elements that will perform the toggling. I added a wrapper around two elements (the togglers) and proceeded to play around with them.

1
2
3
4
<span class="trigger-wrapper" data-trigger="toggle">
    <a href="" class="tmbtn trigger hidden" data-action="test_toggle"><i class="fa fa-toggle-on"></i> Active</a>
    <a href="" class="tmbtn trigger" data-action="test_toggle"><i class="fa fa-toggle-off"></i> Inactive</a>
</span>

The trigger-wrapper class was added to wrap everything in one molecule.

I added the data-trigger attribute to the wrapper because this is what will determine what toggle type to perform… Is it a straight toggle of two items, show / hide an element, or both?

The trigger classes are what determines what triggers the toggle. These trigger elements will swap out their hidden classes. That’s how they toggle.

Here’s two more HTML examples of the content pieces:

1
2
3
4
5
6
<div class="trigger-wrapper reset" data-trigger="dropdown">
    <a href="" class="tmbtn trigger" data-action="test_toggle"><i class="fa fa-ellipsis-h"></i></a>
    <div class="target hidden init-hidden">
        [Content]
    </div>
</div>

… and…

1
2
3
4
5
6
7
<div class="trigger-wrapper reset" data-trigger="dropdown-toggle">
    <a href="" class="tmbtn trigger hidden init-hidden" data-action="test_toggle"><i class="fa fa-chevron-up"></i> Show Less </a>
    <a href="" class="tmbtn trigger" data-action="test_toggle"><i class="fa fa-chevron-down"></i> Show More </a>
    <div class="target hidden init-hidden">
        [Content]
    </div>
</div>

Notice how these last two items had the “init-hidden” class added, and the togglable content has “target” on it.

Now, for the JavaScript (jQuery) that drives the whole thing… (Assuming that .hidden already exists in your CSS as display: none).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
...
var _toggle_type = '';
...
var $parent = $this.parent();
...
if (typeof($parent.attr('data-trigger')) !== 'undefined') {_toggle_type = $parent.attr('data-trigger');}
...
// In the ajax call of the JavaScript file (data is what comes back in the success function) ...
data._toggle_type = _toggle_type;
data.$parent = $parent;
postAjax(data);
...
// And of course, the switch case for the different toggles...
switch (data._toggle_type) {
    case "toggle":
        data.$parent.find('.trigger').toggleClass('hidden');
        break;
    case "dropdown":
        data.$parent.find('.target').toggleClass('hidden');
        break;
    case "dropdown-toggle":
        data.$parent.find('.trigger').toggleClass('hidden');
        data.$parent.find('.target').toggleClass('hidden');
        break;
}
...

So now, we have a lot of the functionality to handle our togglability.

This completes our addition to the Clean PHP code that I’ve been working on here: https://github.com/gbutiri/cleanphp

OOP PHP Sucks!

Update: Before you bash my head in, let me re-phrase the title… ehem… Today’s misuse of OOP sucks as much as misuse of procedural style.

After considering how the web has evolved, I’ve noticed that is not what you use to code, but how you code it that matters more. Yes, what you use still matters, but how you do it matters more. After trying to work on a project using Zend2, I gave up on it when I noticed the ridiculousness of just rendering a page with some dynamic data on it. Autoloading unnecessary libraries, adding layers of abstraction from propel which really all it does is use unnecessary clock cycles to do the same thing that writing your SQL inside a string, building objects that use something like 5% of its functions, “ingest” template files to create some sort of rendering, adding smarty templatizing on top of it that needs to convert to php tags anyway, and finally, the end result.

For real? We NEED to do all that to just render some dynamic page? Wow! We have come a long way in abstracting the simplest solutions into difficult to understand spaghetti code. I’ll explain what I mean by all this.

Let’s look at what actually happens when a web page gets rendered for end users… after all, that’s typically the medium that end users get to interact with in order to have productive or entertaining lives.

It’s a long trip. Hope you brought a book along for the ride.

– Request gets sent to a server via URL inputted by end user typically via the address bar.
– That url gets to travel to DNS servers that send the request to servers identified by IP addresses.
– The server is hit, the server then access its first landing point (htaccess and folder structures) and makes a smart decision in order to try to build some sort of a response to send back.
– At this point, the server will either send you back a message about how it can’t find a file requested, or continue to try to render something to send back.
– Let’s say some default index.html was found without complicating things too much. And let’s say that this file contains basic html, and hopefully somewhat valid html code that gets served to be sent back as data packets back to the original requester.
– The html code comes back to the browser, gets interpreted by the browser, and the browser does its thing to render out the HTML, style with some css code, and run its internal JS engine to see if it has something to do on the client side.

This is where things can get complicated, but why? We don’t have to complicate things. Let’s keep in mind that the final response is simply a long line of characters. There’s absolutely nothing “object oriented” about it. The browser simply takes what it receives and tries to do its job. It’s that simple.

Yes, some JS gets interpreted as objects by the JS engine within the browser, but that’s not for this discussion. Let’s focus on why PHP shouldn’t be OOP.

Back to the server… Here’s what the browser wants:

< html code >
< script code >
< style code >
< html code >
< html code >
< more html code >
< maybe even more script code >

Done. The browser interprets what it gets… or tries to… and renders stuff on the screen. The browser is your application layer.

I cringe every time I hear web developers saying that they’re building an application… You’re nor building squat. Your job is to create browser readable code. That’s it. Just because you’ve overcomplicated your code so much that only you can understand it half the time does not make you an application developer. Creating a browser… now that’s application development. Until that point, you’re just creating a string of characters.

So, then, webpages started to evolve to create dynamic content… So whenever you land on the root of a site, you’re really hitting a script file… something like index.php. Somewhere on the server, in a configuration file, we’ve created the logic to say that the initial point, the entry point should be index.php… we call this the Directory Index.

This file can simply contain pure HTML code just like your *.html files. But… you can do something magical on them. You can render different content. PHP (as well as VB Script used to do), can make this happen. By using the php tags () respectively, you’ve just told the php engine that there’s some code in between. So… PHP, do your thing. Look between these tags and do some work.

I keep hearing from so many new aged developers about keeping your code separated… something about code separation makes things cleaner. I couldn’t agree more… when you’re talking about keeping your styles and JS separate, that’s a great idea. When you’re talking about adding PHP tags in your pages, why are we so scared? the code is completely separated. There’s HTML and then there’s dynamic code inside that HTML that makes sense to have there. The page becomes a template. You don’t need to have template files nested 10 directories deep. The php file itself becomes the template.

I’ve actually heard this argument before… “But php tags look so ugly… so I use smarty tags”. O_O … Are you an idiot? They look ugly? So that’s why you have to add a layer of abstraction on top of it? Adding smarty is not so smarty, is it?… That layer of abstraction just made your code slower because the PHP engine has to now convert ALL of the curly brackets on the page to “ugly” php tags… You know what? If php tags are ugly, then smarty tags are stupid. If that’s the case, I’d rather be ugly than stupid.

It feels like abstraction has gotten out of hand where we now pull HTML templates inside some private function inside a file nested another 10 directories deep.

This mentality of super abstraction is what I have a big issue with when it comes to development for the web. It’s typically engineers who consider themselves super smart coming from the world of Java or C++ who somehow believe that coding on the web is the same thing as console, or application development. It’s not the same thing.

Let me explain so someone as smart as you can understand. Java development doesn’t have a browser for which you need to write a string. It doesn’t have multiple languages to handle, such as HTML, JS and CSS. It’s one code… assembly. And of course, to make it easy, there have been compilers built that can convert all of your nicely written OOP code in code that the machine understands. It gets compiled, and your code is typically living within the Java engine that you downloaded and installed (not a browser, it’s an engine with which the user never directly interacts). It stays in RAM. HTML code doesn’t stay in RAM. It gets put on a disk (browser cache). The CSS, same thing. The JS, same thing. All those pretty objects that you took all that time to build, are gone! Not in memory. Not on the disk. It’s all gone. Oh, you want to access them? Well, then we have to hit a database on a server somewhere far away from your home in order to re-build whatever you’re seeking. Get it? It’s not the same thing as app development.

If you work with PHP, you’re not building any application. You’re building code that’s to be interpreted by the PHP engine on the server in order to deliver a string of characters back to someone using a browser.

Applications, on the other hand, get installed on consoles, and PCs, and hand held devices. Upon starting the application, a whole bunch of stuff gets loaded in memory, and then the program itself uses those bits from memory. And all that stays in memory while the program is active. Only when you chose to quit the application does the application unload itself from memory. All those “object pointers” for functions and variables get cleared out.

In the end, I suppose some will never understand the difference between application and web page no matter how much you try to explain to them. Or, someone will come along claiming that they’re working on a huge website where OOP is saving their life, or some brainiac engineer claims that they don’t see how they could have built their “web app” without OOP. Obviously they’re not intelligent enough to realize that before “web oop” ALL websites were done without OOP, and they did just fine, because they built them well. It was how they coded them that mattered, not what techniques they used.

This was my rant. Thank you for listening / reading.

Update: After careful consideration, and many of your comments, I’ve come to the conclusion that it’s not OOP that I hate. I think it’s the misuse of it. Writing your models in a way that you have to load all of them for something simple… writing your SQL queries so you have to loop through database requests because you must use ORMs… instead of just writing a query that’s more complex, but increases performance 10 fold… Oh, and what’s wrong with SQL itself? It’s an awesome language to know.

I believe that it’s the way coders have been writing code that’s more of an issue for me than the actual style. PHP is not Ruby. Not everything is an object… especially when it comes to rendering things in HTML.

I’ve been using Code Igniter for my latest two projects and it’s not as painful anymore. I don’t like how it routes things as Apache is much more performant when it comes time to handle routes via Rewrite Module.

I also miss the idea of finding a page in the root (about.php) for an “/about.html” request. However… if you check your routes, it should be no problem to navigate through controllers then views (partials too). Still… looking through three or four different files to find what I’m seeking, is more work than I’d like to do… one file… off the root… about.php. Done. I suppose I can do that if I alter my htaccess file, but then… why am I using CI in the first place?

Anyway… I’ll continue to use a mix of procedural and OOP code as I’ve been doing more of lately. (Using 3rd party libraries has become a bit easier).

Once again, thanks for listening. I hope this can help other “non-believers” to understand that we need to understand our needs before we write any code.

I wonder if facebook or google uses any OOP development on the back end in their websites… er… web apps.

All PHP Frameworks Suck… Except for Mine

The thing about frameworks is that they’re built by developers to meet an out of the box solution. Sometimes, that’s a complicated piece of spaghetti code that can be used for anything, such as Zend 2, and sometimes, it can be a simple scaffolding set up in a very opened Core PHP way such as Yii, but still has the tread marks of included files and unnecessary nested functions, with an abstracted database layer.

The problem I’m having with any out of the box framework is this… Well, there are several problems.

1. Layer of abstraction for database.

I’ve heard this so many times before. What if the database changes? it’s easier to change that layer of abstraction than to go through your whole site and change the sql statements.

The problem I have with this is again, lazy developers will always make things worse for the rest of us. What you don’t realize is that by being lazy, you’re destroying your performance. Let me explain.

Typical mysqli statement:

1
2
3
4
5
6
7
8
$sql_i = "SELECT name FROM table WHERE id = ?";
$dbi = mysqli_connect(...
$stmt = $dbi->prepare($sql_i);
$stmt->bind_param("i",$id);
$stmt->execute();
$stmt->bind_result($name);

echo $name;

Ok, still a few functions to run through. Not bad though when you compare with how Yii, or Zend 2 propel queries for the same data. let me explain.

1
$query->select('table')->where('id',$id);

Yes, it looks smaller, but you’ve just added at least another object, and two more function calls. This is in addition to the back end mysql calls that happen to actually get that data. As far as micro optimization goes, this sucks. You’re not just adding two more function calls and an object; you’re adding an object and two function calls for EVERY QUERY that you run against the database.

In one of my previous work places, the lead developer was so obsessed with micro optimization that he would create arrays that would be build with brackets instead of array_push(). Obviously, the function call is more expensive when it comes to micro optimization. So, it’s ok to not be optimized when it comes to database calls only?

Then, they were wondering why their website loads at over 4 seconds. They had over 100 http request calls. No website should have over 25 calls, I don’t care how complicated your business logic. In the end, that’s what matters. Site speed is mostly determined by the amount of http requests. The problem was that with the framework they were using, it would have been nearly impossible to refactor the site to allow for concatenation of css and js files without writing it in Core PHP. What’s the point of this framework? Which brings me to my second point.

2. No flexibility for custom code

No matter how robust a framework is, it will always have constraints. There are limits to the things you can do with it. Symfony 2 for example, only allows for either sessions or cookies to be set in one call. Sessions are overwritten by cookies. So, in the end, we ended up writing Core PHP to handle both being set. Explain to me exactly what the win was there. If we’re going to avoid the framework and not use the framework’s internal functions, what’s the point of using the framework? Only to have it as a “cool” layer of abstraction? Because you think you’re cool that you know the framework?

Updates

Whenever PHP had an update, it was still PHP. New functions that would allow for more things to be done, and deprecated functions slowly making their way out. Slowly. You could still run your old code on the new PHP platform. You didn’t have to change anything, unless you wanted to optimize some of your code.

Have you ever tried upgrading from Zend to Zend 2? Symfony to Symfony 2? A freakin’ nightmare. And what’s ever worse is that with any new update to PHP, you couldn’t take advantage of this new version inside your framework. So, now you’re stuck using an older version of PHP, and a never changing framework, until the new version comes out, not having the guarantee that the new version of your framework will work with your old code.

When PHP updates, it has been usually tested by many more developers than if Yii updates. There’s a larger support group that will help you understand this new functionality. When a framework updates, the only ones that fully understand the framework are the developers of that framework. You have to pick up from the beginning and re-learn it. Sometimes this can take months. And once it’s perfected, a new version comes out. How is this progressive towards development?

PHP on its own is a framework. A much more robust, and opened framework. It will allow you to do whatever you want.

In conclusion, my theory holds true about frameworks. The best framework is the one you build from the ground up. I keep saying the same thing over and over:

“It’s not the tools you use, it’s how you use them”.

Thoughts?

Update: 8/1/2014

Happy Friday! Just to make sure we’re on the same page, I found an awesome article that pretty much states what I stated. Do not use an out of the box framework for project that require long term maintenance. Build your own with as little abstraction as possible, and only make functions out of code that absolutely repeats itself. No parameters. Read for yourself and decide. Yes, it’s a bit long of a read, but definitely worth it!

https://www.simple-talk.com/content/article.aspx?article=1274

PHP Frameworks Suck

It’s kind of funny. After trying to understand Zend 2, I decided that I was happier with Core PHP. I noticed that anyone can pick up any framework and learn it in a few days, or even a few weeks, but to master it, you really need to spend a lot of time with it. I’ve spent 11+ years with PHP at the time of this writing. I know PHP.

Why have any framework? For most do it yourself type projects, just build a website from the ground up. You already have 4 great layers (Apache or server, MySQL or Database, PHP or backend language, and HTML, CSS, JS all in one). This looks like a LAMP stack to me. Why do I like keeping it this simple? Well, you don’t “need” anything else. Really. This is all you need to build anything. And I do mean, ANYTHING! You name your project, and i can build it.

My only caveat is jQuery. I’ve gotten used to it over the years, and in a way I wish I could go back to plain JS. I mean, for the most part, I still use JS, I just use jQuery for selectors / DOM manipulation, events, and the ever so simple to use ajax function. The main reason I use jQuery is because, otherwise, I would just write my own functions to do all these things. jQuery just makes sense to use.

My next task is to convert all my jQuery into JS at some point. Why? Because that’s what the browsers understand. The browsers don’t understand jQuery, or angular, or LESS or SASS on their own. They need pre-processors and libraries to convert all that.

This brings me to my other point. The backend should be no different. PHP is what is already installed on the server. Running PHP code in your files speaks directly to the PHP installation on Apache. You don’t need additional overhead to make things work better. Write PHP, done. You can structure your PHP in logical functions to make it work for you, such as getMeSomeData(), or renderThisHtmlBlock(). But that’s it. At its core, PHP is a great and most opened and powerful framework of all. Why add so many layers of abstraction on top of it?

My next good practice is to write MySQL directly into my php code. Why not? That’s the fastest processing you’re ever going to get without involving overhead. Use propell? Why? Just so you can stack php functions that eventually build out what you meant to say with MySQL anyway? Again, more layers of abstraction? What’s the point? Because it doesn’t “LOOK” like SQL? Is that really a valid excuse? Learn some damn MySQL like a good programmer, and remove all those PHP overhead functions to keep your site optimal.

It’s not what you use, it’s how you use it. Developers have become so lazy over the years, and no one cares about code itself. They treat it like they’re bored of it and just need to add layers of complexity.

The only thing that matters is how the client side performs. All of my projects’ pages load faster than 2 seconds, out of which most load under 1 second. In the end, that’s what matters. And, the turnaround time for most of my development is minutes, not days like most projects dependent on builds.

And I simply don’t want to discuss things like memcached, composer, ruby (for SASS), or any other dependency that’s simply not necessary. Are your websites fast? Then, that’s what matters. I worked at this one company where they would be concerned with micro optimizations such as to use array brackets instead of array_push function. At the same time, they were using propel that would run through dozens of php functions to get data, and their pages were loading in over 4 seconds, with unoptimized images, and over a hundred http requests. I just don’t understand this sort of mentality. These things should matter no matter if you are running an SEO site, or a private LAN intranet. Users will complain when your site loads in over 2 seconds. That’s a rule.

I’ve built many systems over and over and over only to come to the same conclusion. Simplicity just works better. Ask Steve Jobs.

Zend 2 For Beginners Step 2

All right, guys. In response to the Zend 2 For Beginners post, I thought I’d carry on and show more on how not to be afraid of Zend 2.

If you find yourself frustrated with frameworks as I was a couple of years ago, don’t lose hope. A lot of the frameworks out there have evolved to the point where they’re very manageable. If you’re like me though, and want to do pure PHP on your own projects, no one is forcing you to do Zend. And no, using Zend doesn’t guarantee that everyone who will use it will be a better coder, or that your code will be cleaner, or faster. In fact, it takes 10 times more of the processing power to render out a zend call than a pure php call.

But, if you’re involved in working with others on Zend, I’m writing this to show you that anyone with a bit of programming knowledge can pick up Zend 2 and go with it. Simple.

Let’s start!

Here’s the structure you will need for the basic module. The bare essentials to just render out some text.

1
2
3
4
5
6
7
8
9
10
11
12
13
modules
|-- Articles
    |-- config
    |   |-- module.congif.php
    |-- src
    |   |-- Articles
    |       |-- Controller
    |           |-- IndexController.php
    |-- view
    |   |-- articles
    |       |-- index
    |           |-- index.phtml
    |-- Module.php

Don’t be scared. this is only 4 files if you look at it carefully. Yes, it’s a lot of folders, but it’s not a lot of code. Yes, clean PHP could do it in one file, but there is a lot more to worry about as far as keeping track of all of the including, etc.

So, now, let’s look at the first file: The Module.php off of the module root folder:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// /module/Articles/Module.php
// This line defines our namespace. The place where our module resides. Keep this the same name as our module.
namespace Articles;

// Name our class, obviously.
class Module
{
    // this is to load our configurations for routes, etc.
    public function getConfig()
    {
        return include __DIR__ . '/config/module.config.php';
    }
   
    // this it to load our source files (namely, our controllers).
    public function getAutoloaderConfig()
    {
        return array(
            'Zend\Loader\StandardAutoloader' => array(
                'namespaces' => array(
                    __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
                ),
            ),
        );
    }
   
}

And that’s it. Basically, this file tells us to load our module configuration and autoload any controller files we may have.

The next step is to look at our config file.:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// /module/Articles/config/module.config.php
return array(
    'router' => array(
        'routes' => array(
            // this is going to be what we call our route. It's a good idea to keep it the same name as our "link"
            'articles' => array(
                // Yes, this time, were passing in an exact match for the route. No parameters, no trailing slashes, done.
                'type' => 'Literal',
                'options' => array(
                    // Finally, this is what the URL should say to access this route.
                    'route' => '/articles',
                    'defaults' => array(
                        // And of course, we define our default controller and action.
                        'controller' => 'Articles\Controller\Index',
                        'action' => 'index'
                    )
                )
            )
        )
    ),
    // Specify our controller shortcuts (from the controller above)
    'controllers' => array(
        'invokables' => array(
            'Articles\Controller\Index' => 'Articles\Controller\IndexController'
        )
    ),
    // and, finally, where to look for our main file when the /articles link is hit.
    'view_manager' => array(
        'template_map' => array(
            'articles/index/index' => __DIR__ . '/../view/articles/index/index.phtml'
        )
    )
   
);

Simply put, this code above will direct any calls that come in to the right logic in the code and the right template file to use when rendering.

Next, our Controller file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// /module/Articles/src/Articles/Controller/IndexController.php
// Our namespace to define module and usage
namespace Articles\Controller;

// load this for basic controller functionality
use Zend\Mvc\Controller\AbstractActionController;

// define our class for this Controller
class IndexController extends AbstractActionController
{
    // And... define our main action.
    public function indexAction()
    {
       
    }
}

And that’s it with this one. Basically, the route points to this controller to do any sort of logic, or business logic, and calculations before sending stuff to the template for rendering.

And last, but not least, our view file!!! Yay!

1
2
<!-- /module/Articles/view/articles/index/index.phtml -->
This is my Articles Index file.

That’s it. There really isn’t much to it. This view file will produce a comment of the location and some text that mentions that this is my article index file.

If you could resist through this tutorial and the previous one, you can pretty much build your own Zend 2 modules. Yes, there’s a lot more to learn about Zend, which I’ll slowly be covering in other posts, but for now, to get you started to understand how everything is pulled into Zend to render out some simple pages, this is all you need.

I’m also going to teach you how to load scripts and css files into the header. That’s going to be fun. And later than that, I will be covering AJAX calls and partials.

Don’t forget to remove the /articles route from your Application module. 😉

See you next time!