Why I use Safari.
There are many browsers out there: IE6, IE7, IE8, FF, Opera, Safari, Chrome
Then there are tons of mods for each of those. On the mac, a few lesser options (FF, Opera, Safari, soon to be Chrome). I used to scoff at Safari users when it was around the 2.0 release (even 3.0 seemed crap to me). When I adopted the Mac, however, Safari fell into a different light for me. The number one reason it did was because of it’s speed.
In the 4.0 release, the first thing you realize about Safari is how fast it is. While non-web developers would often remark that there isn’t much of a difference, it’s something you pick up very noticeably when you spend 10 hours in a browser. It’s not that every second counts, it’s just that you notice it and lean towards the one that will save you any time at all.
As a developer, it misses many things like Firebug, plugins (has a few, but not comparable), web developer toolbar, and while Safari has it’s own web-kit based inspector, in my opinion, it’s terrible. You can view the DOM, but not do much with it.
I find that the only time I’m not using Safari is when I need to do some post-render editing using firebug, or test out a plugin in FF; any other time, Safari and it’s speed an UI dominate for me. My only hope that it gets a little more plugin compliant to make it more useful more of the time.
Professional CodeIgniter: Review (part 1)
So far, I’m done about half of Professional CodeIgniter by Thomas Myer. As you guessed, it’s about the php, MVC framework CodeIgniter. While I’ve spent a lot of time online at the documentation, tutorials, etc., I’d preferred to grab a book on it (the only one I could find that’s available) to get a more formal introduction.
In terms of how it’s written, I was very impressed by it very early on. The language is very clear and concise, and Myer does a great job of walking you through a very real world example. I was actually blown away by how well he can articulate fairly advanced concepts. However so far this was the highlight with some major let downs.
For me, I came into this expecting a book on how CodeIgniter worked, how it’s structured, it’s benefits, etc., but after having read half of it so far, it’s become much more like a basic php web development tutorial. There is a recurring tutorial that is themed throughout the book of how to setup a rudimentary e-commerce site. When the tutorial begins, some CodeIgniter specific code is presented, with outlines of the helper classes, organization of a request/mvc separation, etc., but very quickly, most things specific to the framework are forgotten, and CSS/JS/PHP becomes the focus.
Additionally, the focus seems to be targetted at a beginning. Perhaps that was the intention, but it was a real disappointment for me. This framework is exceptionally powerful, and while it’s seeming to operate much more like a library than a framework such as CakePHP, it has tons of usage, most of which doesn’t seem to come through in the first half. A lot of time is devoted to making ajax calls to a controller (understandably a notable topic, but not specific much to CI), pages and pages of CSS (at one point there was a 3 page stint of pure css code, which didn’t seem very relevant as it’s a PHP/CI book), and even JS.
I believe I understand the intention; Myer wants to take you from concept to delivery, and show you how everything in between fits together within the CI framework; however because of this, I’ve felt that the power of CI has been left behind for me to figure out in their documentation.
While CI does push convention over configuration, it does seem to come across as a very strong and powerful library rather than a framework (with some pre-req’s that push it into the latter category). This isn’t necessarily a bad thing, but since it’s the case, I would expect more of the library to be explained, and how it could be useful, rather than walking through a tutorial that is targeted much more at the new php developer delivering a larger project than they’re used to.
I’ll follow up with my second half of the book review shortly.
Script/Asset abuse: this is getting ridiculous!
Frameworks like YUI, JQuery, Mootools, Dojo, etc., are arguably the best thing to have happened to JavaScript in 10 years. I remember when I first learned about their existence. I was coding my own animation script (functional, not OO, and definitely not efficient) that didn’t do anything fancy; just scrolled up and down. I remember then hearing about dojo, and thinking I’d wasted so much time.
Then what I did, was go around to all the different frameworks. I don’t even think JQuery existed in it’s current incarnation at that point (December of 2005), and I looked around at as many as I could (dojo, mootools, and a few others that have since become relics). This post though, isn’t about the greatness of these frameworks; rather it’s about the terrible abuse.
With any new technology, there will be people who embrace it for ease of use and creating a new standard, and then there will be those who completely abuse it. The screen shot below is a perfect example of that (click it for the full size):
If you can’t see what I have a problem with, then you need to leave this post right now. For everyone else, this is an absolute joke. This is for a travel promotion site called StudentCity. My count of javascript assets: 20 (excluding any dynamically load ajax/jsonp requests). My count of css assets: 11.
These tallies were retrieved via after the DOM had been rendered, so they may not match up perfectly with the source, but I assure you they’re accurate.
If you visit this site, you’re not going to notice too much. A few swfs, a bit of animation, and a few non-css related hover effects. In no way, should this account for the number of requests for just js/css assets. It doesn’t make sense, and is terrible programming/development. I understand that in many projects, control is sometimes non-existent. You need to conform to someone elses demands, some other developers tendencies, or some other designers inexperience. But for the firm who developed this site, if anyone had taken a look at the source after it had been finished, a huge red flag should have gone up.
Concatenating files is easy; minimizing requests is easy, and a faster client side render time will actually make you money, for a relatively low cost (maybe 2 hours). This speaks to what frameworks are doing these days.
JS frameworks, and even php/server side ones like CakePHP and CodeIgniter (ones I’m working with now) are leading to a generation of websites and applications that were developed by people who have very little idea what they’re doing. I don’t think it’s much different than the age of Frontpage/Dreamweaver/GoLive developed sites, but it’s certainly not something that you should be paying for it you’re working with a development firm. It’s annoying as a developer to see this, and probably a do-or-die thing if I were to be working with or hiring another developer to work with me.
“Getting Real” by 37 Signals: Review
“Getting Real” by 37 Signals is a very specific read, for a very specific audience, but it does a tremendous job outlining a different approach to web application development. That approach revolves around getting something ‘real’ out, usable, and able to gain traction. This is the strongest point that is made repeatedly, very similar to a Seth Godin read which constantly reiterates the same point, over and over again, until it’s become clear.
Getting Real’s initial mission is to aide anyone involved with the deployment/development of a web application to successfully get it used. It does so by beginning with having you, the owner of the application, define it’s purpose, it’s audience, and goes through all the different life cycles of the application. These include the design process, hiring, marketing, pricing, customer feedback, and more.
While each of these sections could be very well documented and discussed, what comes through the most in Getting Real would have to be it’s optimism of a minimalist approach to web development and design. This stretches from the initial feature sets, all the way through to the number of people required to launch it, and how they market/advertise this launch. Less is more in the eyes of Getting Real, and they do an exceptional job explaining why this is.
Drawing from a professional history that includes Basecamp, the Ruby on Rails framework, Highrise, Writeboard, Campfire and more, Getting Real is able to back up their claims that less features is most of the time better than the competitor with more features, through real world examples of their success and their history.
Being a user of Highrise, a lean CRM web service, it is very clear from the onset that 37 Signals, the company behind all these services, believes firmly and practices stricltly the process of less is more. Highrise has a very limited feature set compared to other CRM systems, however the fact that it is so lean is what makes it so easy to get in, and begin working. The learning curve varies from none to very little, and it’s flexibility in a few areas (eg. tagging) make it as flexible as the user/business needs.
My contribution to this discussion is something that’s taken me a very long time to understand, and something that a lot of other people could easily disregard as a cop-out: if you are developing something that has competition (everything does), figure out the reason you want to compete, that 1 specific reason, and do that and nothing else.
So for example, back in the day I created a couple networks/sites/app’s that allowed someone to post a vacation property they owned, and I would do the SEO/SEM for them (they would pay me a yearly fee to post on my site) which would then send them inquiries. A really simple directory service. Now there were many out there, and while often a reason for creating a product or service will be to make money (which I thought about too, obviously), my reason for competing was because I hated the design. vrbo.com is one such competitor, and their site is 10 times better than it used to, but still looks horrible. It’s functional, but in my eyes, was horrible and I wanted something better.
But rather than spend 95% of my time on that one thing, the aesthetics of the service, I tried to mimic all the functionality vrbo.com had, AND improve the aesthetics. Like most businesses, it failed. I made some money, but very trivial compared to the market and in no way sustainable. But over the past little while, it’s become clearer to me that if I’m trying to compete in a specific realm, that realm should be 95% of the focus. It sounds easy and obvious, but for someone starting their own business, it’s so easy to want to do everything better. You tell yourself ‘well if i do everything better than my competitors, than the custom will have to pick me’. But all this does is lead to a lot of wasted time.
Getting Real is a great read for anyone who develops sites/applications. It will fairly radically change the way you look at feature sets, deadlines, team oriented development, and more than anything, priorities for your sites/applications.
“User Interface Design Heuristics”: amazing article!
One of the best article’s I’ve read in the past month is entitled Heuristics for User Interface Design
In short, it’s a set of suggestions rather than rules, that should be kept in mind when designing a user interface or experience. I’m tending to lean away from the word interface, as an interface is only good if it’s experience is effective. Gmail’s experience is what affects me, it’s interface is just what I look at rather than what I use.
What’s even more impressive about this list is it was first developed in 1994. I don’t mean to sound condescending in terms of advice coming from 15 years ago, but it’s shocking to me to find interfaces such as Google’s, Twitter’s, and Basecamp’s so incredibly in line with every single heuristic recommended.
My personal favorites:
- Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. - User control and freedom
Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. - Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
JSONP vs JSON: amazing for API’s
I was doing some search and found http://ajaxian.com/archives/jsonp-json-with-padding as well as http://ajaxpatterns.org/On-Demand_Javascript
My reason for searching was I was trying to understand why some developers use the term JSONP vs JSON. JSONP standards for JSON with padding. The padding is supposed to give the JSON a little more flexibility. Let me try to convey in my own words the benefit.
JSON is a great storage format for browser community (and even further than that, db storage, but that’s for another post). The problem is, with AJAX (terrible name considering XML is hardly ever used; standing for Asynchronous JavaScript and XML), the method for deploying techniques is no longer just the XHR object. It can now be deployed via dynamically written <script /> or <link /> tags. You can write to the browser something like:
<script type=”text/javascript”>
[{'wtf':'yo'}]
</script>
This is a json object, and while I use the format exclusively for ajax calls that use XHR, cross domain requests using the <script /> and <link /> tags are becoming more and more common. It’s one of the easiest ways to get by the cross domain restrictions set up by browsers (which I think is being alleviated in the next ECMA/JavaScript release, btw), but the issue with just spitting back JSON is it doesn’t do anything. Ya, it gets added to the dom (sort of), but it’s not even assigned to anyone; my object [{'wtf';'yo'}] exists, but is basically in limbo. This is JSONP’s territory now.
Let’s say that JSON string is accessible via olivernassar.com/wtf-yo/
As it stands right now, it’d be spitting out JSON, but if we modified the API to accept a uri such as:
olivernassar.com/wtf-yo/?callback=doSomething
And returned:
doSomething([{'wtf':'yo'}]);
That’s is JSONP. You can imagine all the possibilities. I’ve been using it for some time via google/yahoo/facebook API calls, but I never knew the name. I sort of assumed it was a technique that didn’t have a name, just a reason. But I suppose client side development needs a name for everything. Too many techniques to keep track of otherwise.
I’m not sure the usefulness of JSONP will be felt by man. If you’re developing, like most people, internal systems that aren’t meant for outside usage (eg. api’s) then you can get away with JSON responses via XHR, but the second you cross into the territory of allowing other people access your data via a client side or server side/xml api, JSONP becomes really flexible and powerful, yet easy to implement.
Caching is easy; releasing them isn’t.
When developing web app’s that are going to even moderately scale, caching will be your saviour. Whether it’s assets such as images, js files, css, or data sets such as records from a users table, xml files, or whatever else, caching is key.
But when dealing with data sets, such as user records, posts, comments, or whatever else, caching them will not be the hard part; knowing when to release/renew them will be. For example, if you were to cache the 10 most recent comments for a blog post to prevent sql hits to your database, there are a few times you’d need to release/renew them:
- A new comment is added
- A comment is deleted
- The pagination changes from 10 to some other number
- The blog post is deleted
While this may not seem like a big deal, this is just one situation in which the comment data is used, and just one type of data set. Image 20 different tables (common) and more than one place where a data set is shown (very common; for example a widget on your homepage that shows the last 5 comments for all the blog posts, etc.)
Having a clear naming convention for your cache keys is very important; probably the most important in terms of keeping your caching layer organized. It makes it easy to track cache’s that aren’t working properly when the key’s are something like ‘User[1]->Comments(last 10)’ rather than a sha1 representation of the sql query that produces the results.
Just a tip.
php’s foreach on a string? you can do that.
Reminder to self:
Normally, to do a foreach must be something like array(”oliver”,”nassar”). I’ve run into a situation where I didn’t if a variable, lets say $wtf, was an array or just a string. Running foreach on a string results in a notice like “Warning: Invalid argument supplied for foreach() in /random/file/path.php on line #line-number“.
Just write this, and you should be good:
foreach((array)$unknown as $key=>$value)
echo "go nuts.";
?>
What framework does php.net use? Answer: I don’t know.
I’ve been looking at frameworks a lot lately. Mainly for an upcoming project, but also to getting a better understanding of MVC based development, as well as components/helpers for web develop
ment. That made be ask the question, what framework does php.net use for it’s documentation/downloads site?
I read somewhere that Rasmus Lerdorf, the guy who invented php, who went to University of Waterloo, by the way, felt particularly fond of Code Igniter. I’ve looked at it, and heard great things mainly due to it’s ease of use, but echoing Rasmus’ thoughts, if feels much more like a library than a framework, at least to me.
That’s not a bad thing; Rasmus’ meant that positively. I personally don’t think you should be relying on an open source distribution to do the thinking for you. I’ve run into many people who claim to know javascript, but what they really mean is, is that they know how to use a framework like MooTools, JQuery, or YUI. Knowing JavaScript takes much more time, and takes a higher discipline. It’s not for everyone, but it’s not different than someone knowing how to use Dreamweaver or Frontpage, and advertising that they know how to develop website. You don’t know how to develop website, you know how to use a program that writes the sites for you, much like if you’re using a framework, you know how to use an open source distribution to help you write a website.
I’ve been playing a lot with CakePHP lately, and that, in my mind, is a true framework. Everything is native to Cake. Their site is very intimidating, and their framework is VERY expansive, but it’s therefore very powerful. I’m not sure it’s exactly what I was looking for, but it’s given me invaluable insight into framework development for php.
This then leads me back to the question of what php.net uses. My guess is a custom framework; not symfony, or cake, or CI, or zend or any of those guys (probably because they came about way later than php.net), but I’d be interested to know what they do use, and if they’d open source it. For now, I’ll keep working on my own framework that is geared towards being lean, and requiring me to do a lot of the heavy lifting for maximum flexibility. Hopefully I’ll open source it someday, and it’ll be able to meet the needs of people like me for whom Cake was too much, and CI (Code Igniter) was too little.
What to expect from olivernassar.com
This is my first post for olivernassar.com. My posts will be centered around, primarily, web development and design, user interface design, user experience, start ups, coding practices, and programming in general. From time to time, music posts will be found. Additionally, vents/opinions on companies/products will come up.
That being said, this will be a fairly subjective blog, dedicated to the web as a whole. All emails and comments are welcome, and moderation will be turned off for a while.
Some topics coming up shortly will include book reviews, framework reviews, framework choices, and some advice on the freelance/consulting circuit. The languages I currently focus on are (in MVC inspired order):
- SQL
- PHP
- XML
- XHTML
- HTML5
- JavaScript
- CSS
The frameworks I currently focus on:
- CakePHP
- Mootools
Going along with that, however, you may see the odd post regarding RoR, JQuery, or whatever other framework that may possibly connect with my personal favorites.