I have been a long-time Google Chrome user, but have been wanting to switch to Firefox for the past several months, but could not get myself to do it full-time. The interface was a bit dated, and the browser in general didn’t feel faster. I used Firefox Developer Edition for a while which had the newer UI now available in Quantum, but the lack of plugin/add-on support killed my web surfing experience, and I ultimately went back to Chrome.
Then everything changed when the Firefox team announced Firefox Quantum. I downloaded it to try it out, and was off to the add-on site. The team did a good job ensuring most of the popular add-ons were up-to-date and working with the new changes in Quantum. I was able to quickly find and install the add-ons I needed, and have been using Firefox full-time ever since. It’s a joy to use, and consistently uses significantly less memory than Chrome. It’s my new go-to. Congrats, Firefox team – thanks for the hard work and the great release!
Last year, I committed to launching 4 new projects by the end of the year. I did succeed in that goal for the most part – I launched 4 new projects, including the Countism mobile app that has gotten some very good reviews so far. In the end though, I didn’t really feel that successful, and only felt like I had one really solid project. Continue reading
I was recently part of a project where, upon asking for content for the requried “Frequently Asked Questions” page, I was invited to a meeting with the objective of “brainstorming content for the F.A.Q. page”. It was painfully ironic. How can we possibly list frequently asked questions when we haven’t even launched yet and no one has asked any questions?
The meeting (video conference call) started, and I decided to stay silent for a little while to see how the call would play out. The project stakeholders begun by going over the F.A.Q. sections on a bunch of other websites, and compiling a short list of all the questions they would need to write answers for. The list included things like “How can I contact you”, and “How can I reset my password” – questions that will likely never be asked unless your UI/UX is terrible. Continue reading
The age old private vs protected debate has been re-ignited in the PHP community recently following the decision of Doctrine2 and Symfony2 to make all class methods private until there is a very clear and proven reason to change them to protected or public. The intention is a good one – to ensure they are providing a clear and stable API through intentional and known extension points that they can better test and support. Fabien (the creator of Symfony) points to this benefit in an article of his own explaining the thinking behind the decision. The primary started point of Fabien’s article and the driving thought behind this whole change and philosophy is (emphasis his):
Having a few well defined extension points force the developer to extend your library the right way instead of hacking your code.
The problem is that this kind of thinking is a slippery slope that kills the spirit of programming. It alienates the more pragmatic developers within communities. Telling other developers that you are going to force them to work with your code in some pre-determined "right way" is an incredibly arrogant statement to make. more Instead of letting the codebase grow organically and be modified or extended at will, you handcuff developers and send them a different message. Allow me to re-phrase it using my own words:
I know the right way to use this code and I have thought of all the possible use cases. If you don’t agree, then you have to prove me wrong and wait until I either agree or figure out a better right way for you.
This is the real message developers hear when internal code is private scope or marked with the final keyword – a message that they have arbitrarily limited power and ability to make changes where they need to. But it doesn’t stop there.
When you take the position that all methods should be private unless proven otherwise, you plant a seed of fear in the developers that use your code. Fear that whenever they may have to veer off the beaten path to meet a project requirement they won’t be able to. Fear that they might miss deadlines waiting for the "right way" to enable the functionality they need. Fear that they might have to modify or hack the actual file or class they need to change the behavior of to achieve the functionality they want within the project deadline because they are not able to extend it.
Using private scope removes the fun from programming and kills the hacking spirit by creating fear through the knowledge that you will not have the ability to make changes anywhere in the codebase you need to when you need to. You are no longer in control of your own code. You were forced to submit to a nanny state mentality by sacrificing your freedoms to modify the code for the promise of future stability and safety. That’s not a fun place to be when you’re on the receiving end, and it’s not a policy I would ever consider enforcing with my own code. I sincerely hope this line of thinking does not proliferate within the PHP community and infect other projects.
I’ve spent the past few weeks here at work researching and playing with NoSQL databases (and especially MongoDB) for a new feature we’re developing that doesn’t easily fit into a relational model. And so far, I really like what I see. The profoundness of the shift away from the relational model and the implications that has just blow my mind. You no longer have to fragment your data to persist it . You just store it. That’s it. No more hours toiling over the design your table schema and how to break apart the data you put together just to fit it into a relational model. You can now store your data exactly how you use it in your application, with no other special needs or impedance mismatches. Going back to an RDBMS system now just seems illogical – it’s like breaking apart a camera tripod just to fit it in the same standard size case you’ve been using for years instead of just collapsing it and finding a different case that fits it better. All that effort you go though tearing down your tripod and putting it back together every time you use it is wasted and unnecessary. It’s a symptom of the larger problem that your case doesn’t fit your tripod. more
Once you fully get the NoSQL viewpoint and the implications it has on the future of data storage, you have one of those “why didn’t anyone think of this sooner?” moments. And yes, I know key/value stores like memcached existed long before this whole new “NoSQL” movement, but it’s not quite the same thing.
Object databases are an interesting case. They are in the “NoSQL” category and solve the same problem other NoSQL databases do – creating a storage mechanism that fits your data instead of making your data fit a predefined rigid storage mechanism. So why didn’t they catch on? What gives? It’s anyone’s guess why object databases didn’t catch on and achieve widespread adoption, but one thing is for sure – object databases really missed the boat while other NoSQL database technologies are running rings around them.
The primary problem is that most object databases are designed for a specific language, like Java or .NET. Some have more language support than others, but the problem is still the same – by integrating in directly with a language’s object model they depend on specific language implementations, which severely limits adoption. They solve the impedance mismatch problem that RDBMSes present, but fail to provide language-agnostic data persistence and access , effectively tying their use to specific technology stacks and platforms.
The Best of Both Worlds
NoSQL databases are gaining traction like no other database technology has in over 30 years. The reason is that good NoSQL databases solve both key data storage problems: impedance mismatches AND language-agnosticism. By storing the data in an intermediary format like JSON (or BSON) and allowing custom file content types, the focus is on the actual data itself instead of specific technologies or data models. The technology stack becomes irrelevant, and the walls to gaining user adoption crumble.
The bottom line is that NoSQL databases are not just the latest fad. They represent a fundamental paradigm shift in data storage and are an entirely new way of thinking about how to store and access your data in a way that makes sense for your actual usage. NoSQL databases are absolutely something you should be paying attention to and following closely – they are a strong contender to the RDBMS model
and will likely become the de-facto data storage choice for most new web applications within a decade and a solid alternate choice.
Packt Publishing announced the winners for their annual Open Source CMS Award in November, and since then I have been a bit disturbed that the 2009 winner was WordPress. My first reaction was this:
"… So a blogging platform won the content management system award? How sad is that?"
My knee-jerk "how sad is that?" reaction comes not because I don’t think WordPress is worthy, but because of what it implies about the state of other open source CMS projects. The reaction comes from the fact that a blogging platform is kicking your CMS’s ass in its own category.
The MVC design pattern has been getting a lot of attention in the past few years. It seems like a new MVC framework pops up every week, and discussions about MVC have become commonplace throughout web programming communities.###MVC is Here to Stay
While MVC is certainly the "new thing" again (funny, because it actually dates back to 1979), it won’t be a passing fad, and it won’t fade quickly – at least not on the web.
Solving the Fundamental Problem of Web Development
Unlike most dektop applications which can be completely coded with one or two different programming languages, websites are a mix of several different programming languages that are constantly changing. The typical website or web application in composed of no less than 6 different programming languages:
- Server-side language like PHP/Ruby/Python/.NET, plus:
- SQL – (Variants: MySQL, MSSQL, PgSQL, SQLite)
- XML (Plus specific formats like RSS and Atom and possibly XSLT)
- JSON if the web application has an API
- And who knows what else a few years from now…
As a result, the code naturally has to be separated somehow, and the same content has to be able to be displayed in many different formats (most commonly HTML plus XML and JSON for APIs).
I am currently working on my own little app as a side project (who isn’t these days?), and I have determined that I’m close enough to launch that I needed to start generating a little buzz and getting at least a few interested people to signup for a limited closed beta test before it launches. Problem is, I consider myself much more of a programmer than a designer, but I still wanted the splash page to look good and get visitors familiar with the brand I was trying to create. For that, I needed a logo. So while I don’t really consider myself a graphic designer, I went ahead and followed David’s advice on the 37signals blog about doing it yourself first. And man was he right.
Just when I was seriously considering spending some of my own hard-earned cash on a logo by a professional, holding a design contest, or taking on a design partner, I instead took about 3.5 hours out of my lazy Saturday afternoon football watching to attempt to make a logo for my app on my own. I had the basic idea in my head of what I wanted it to look like, but I know that most of the time what I picture in my head and the end result rarely look even close to the same when I am the designer. Sometimes that’s okay. The end result logo (pictured) actually ended up looking very much like I had pictured in my head, and (at least in my opinion) looks great.
So with a few hours on a Saturday afternoon doing it myself first, I managed to save myself at least $300 and a few days waiting for the end result. Moral of the story: Always do it yourself first!
Benchmarking and performance concerns should be one of the last things you address while building your application, but it seems as though, in the PHP community especially, it’s often one of the first things novice developers think about.
Any PHP developer who’s been in the community for a while has heard preposterous claims like “use single quotes (‘) for strings instead of double quotes (“), because it’s faster”. That is, faster over the 100,000 or so iterations it took the tester to generate a number sufficiently large enough to justify the claim, with a particular version of PHP, in a particular development environment in which it was tested.