Ok, so we’ve briefly discussed the importance of figuring out what your software should do, so what will my software do? What I need to do is sit down and write out what the software will do, and review that from an experienced developer stand point and figure out where I’ve not been precise enough. Let’s start with this (based on what MultiBlog the desktop app can do):

MultiBlog will allow users to register an account. Within that account they will be able to configure multiple remote blog accounts. They will then be able to write blog entries and cross post this to multiple blogs within multiple blog accounts.

That’s great. But that’s very high level, clearly that needs some expansion. What details are needed to register an account? What makes up a remote blog account? How do they write entries? How do they cross post the entry? It will serve as a statement of intent, but it’s light years away from a specification. I’m going to take one aspect of this and expand it as a worked example, that will be the writing of entries.

MultiBlog will allow a logged in user to write blog entries within a browser-based WYSIWG editor with the option to edit the raw mark-up of the entry. The software will support drafting of entries.

An initial screen will list all current, unposted draft entries the user has been composing. The user will be able to select a draft to continue editing, or to create a new draft. Upon selecting one of these options, the user will be presented with an editor screen.

The editor screen will contain controls to capture:

• Post title
• Post body
• Post tags
• Current Mood
• Current Music
• Post date and time

The editor will autosave drafts every 5 minutes, and allow for manual saving of drafts.

In addition, in a future release, the editor screen will integrate to external web services to insert content, for example, product information for Amazon content or Flickr images. This will allow easy blogging about films, books and photos taken etc. However, this will not be implemented for MultiBlog Online 1.0.

This is better. There is much more detail. However, there are still blank areas, what exactly will the WYSIWG editor do? What are it’s features? This is something I won’t expand as I’m just going to go with one of the leading open source, browser based WYSIWYG editors for HTML, after evaluating them against the other requirements in this area. One of these is of particular interest for several reasons. The final paragraph of my requirements for the Blog Entry Editor is a future requirement to allow easy insertion of data from Amazon, Flickr or other web services. Whatever editor I pick up is going to have to be easy to extend/adapt so I can use widgets to pull that information across.

This is an isolated packet of requirements. How does this interact with the rest of MultiBlog? What else will the rest of the application do? Obviously, I need a full MultiBlog requirements specification. I don’t intend to post that as a Blog entry. I will produce a document, which I will publish, that covers and elaborates everything I intend the application to do.

That will then form the basis of my high-level software design and architecture.

Popularity: 32% [?]

Typically for me, I’ve got sidetracked for the last few articles with technical stuff. What platform? Where to develop? Get the development environment set up. All that kind of stuff. Of course, that just hand waves away the fundamentally most important aspect of writing software:

Clearly identifying what you are going to produce, what it is going to do and how it is going to do it.

That is where both bespoke and product development most typically comes unstuck. Not agreeing up-front what you’re going to write and what it’s going to do. Now, for bespoke work, where you’re creating a custom solution tailored to a customers exacting requirements, that’s a massive issue. There are many problems en-route. Such as simple mis-understandings and, even worse, the things the customer thinks go without saying.

These are the things that cause scope creep and late delivery. Much bespoke work involves fixed price and/or timescales, so this is a major issue.

Of course, in the product world it’s not such a serious issue as much of the time. Obviously, there are issues making sure that your software does something that customers want, and does it in a way that will make them want to pay for it. Also, there are issues with making that first release in a timely fashion to start getting a revenue stream. Or some users and feedback etc.

But for product software, the biggest failing at this requirements capture phase is short-termism. You might decide that the software is going to do so and so. All very well and good, and that might lead down a certain path. That path might turn out to be a cal-de-sac when you realise later on that it was obvious that so and so was right, but, implementing it in such a way means you can’t do a natural extension of so and so that could have been an obvious thing to want to do later right at the start.

So, before I get any more carried away with the platform and the development environment, I think it’s time to sit down and figure out what the basic features of Multiblog are, and where the road map will take it in the future.

Popularity: 33% [?]

We now have Apache and PHP on a USB Key. We need a database, so we’re going for MySQL. Unfortunately, this step is much like getting Apache working. We have to download the installer from the MySQL site and install it. Then we take a copy of the installed directory and copy it onto the USB key and uninstall from the host machine.

Once we have this copy, we need to create a batch file to launch it and test it. This removes the need for a custom my.ini with path fixes, because we can pass those items on the command line. My batch file contains:

\development\mysql\bin\mysqld-nt.exe --basedir=/development/mysql --datadir=/development/mysql/data --port=3306 --console --standalone

We should now have a working Apache, PHP and MySQL, and we just need to tie it all together. To do this, I’m going back to the firepages method. I have a start.php script that contains the following:

<?php
echo "starting MySQL ....\n";
pclose(
    popen(
        'start \development\mysql\bin\mysqld-nt.exe --basedir=/development/mysql --datadir=/development/mysql/data --port=3306 --console --standalone'
        ,'r' )
    );
echo "starting apache....\n";
flush();
pclose(popen('start \development\apache\bin\apache.exe','r'));
flush();
sleep(5);
echo 'opening localhost';
exec( 'start http://localhost:8080/');
?>

And a start.bat file that launches PHP in an appropriate fashion to finish that off:

/development/php/php.exe -c /development/php/php.ini -f /development/start.php

There we go. All done. Of course, this could be acheived by downloading XAMPP (Lite), however, this way we know how our environment hangs together and can easily upgrade and extend it.

At a later date, I’ll be getting PEAR working, installing XDebug and getting a PHP4 instance in here. But for now, we have a sufficient development environment to get on with things.

Popularity: 25% [?]

This morning I was reading a post by Jeff Atwood about Mike Gunderloy switching away from Microsoft. Jeff says:

Still, his [Mike Grunderloy's] attitude frustrates me, because it falls so egregiously into the stereotypical, religious love/hate dichotomy that I’ve observed again and again in software developers. You either love Microsoft and use exclusively Microsoft products, or you hate Microsoft, and you vow never to use any of their products ever again. There’s nothing in between. No middle ground.

This is something I too see all the time. People take their choice of development platform incredibly seriously. Personally, I’ve not seen too much positive Microsoft love, in my life I’ve been more exposed people with a blind and all consuming love elsewhere. More specifically, I’ve been exposed to Java Zealot’s who will not, under any circumstances, accept that anything other than Java is the solution to their problem. I’ve been exposed to Java developers who are Microsoft haters, and Microsoft haters who are not Java developers also. But overridingly, the zeolotry I’ve seen has been for Java.

My professional work has had a predominately Microsoft bias. I’ve ended up for whatever reason falling into teams using Microsoft tools and products to build solutions. My non-professional work on the other hand has had the opposite bias. I’ve tended towards Open Source languages and tools such as PHP and other scripting languages. I’ve used Delphi heavily. And when I have been using Microsoft languages (mostly scripting), I’ve been using non-Microsoft products to write the code (namely Ultraedit).

I’ve even written Java.

I’ve found this to be a huge advantage to me in my career.

Each language I learn, each tool I use, comes with further knowledge and appreciation of the art of programming. Each new language that appears is designed to solve a perceived problem with a pre-existing language, and so comes with a new development ethos.

As language and platform are a religion for so many developers, the communities round these platforms become isolated and insular. There is little cross-pollination of ideas and techniques between these communities. In biological terms, this limits the evolution and growth of development. It’s gene pool is kept artificially shallow.

I’m driven by a deep interest in programming. I love to pick up new tools and new ideas. I find that every time I learn a new language, I find new approaches to common problems, that could work in a number of other languages that I am fluent in. And then I try and take these ideas and use them outside of their spawning ground.

Looking at some of the endorsements I’ve had provided on my LinkedIn profile from ex-colleagues, it’s not just my perception that this has been good for me. Other people have seen the benefits I’ve given previous companies from this breadth of knowledge. I can think outside the box in any language, because I know so many languages. For example, this quote was from one of the senior technical architects in the Java division of my company, a division that I only directly worked with once however, provided input to many times:

“Mike is a very skilled and highly professional developer. Perhaps the most impressive aspect of Mike’s work is the sheer number of languages and technologies Mike knows to a professional standard - no doubt a consequence of Mike’s eagerness to take on, and complete, new challenges which others may shy away from. Mike’s breadth of knowledge makes him a great asset to have around as he is very approachable and will find time to share his expertise with his colleagues.”

As Jeff says:

As a software developer, you’re doing yourself a disservice by pledging allegiance to anything other than yourself and your craft– whether it’s Microsoft or the principle of free software. Stop with the us vs. them mentality. Let go of the partisanship. We’re all in this thing together.

I’m a pragmatist. For now, I choose to live in the Microsoft universe. But that doesn’t mean I’m ignorant of how the other half lives. There’s always more than one way to do it, and just because I chose one particular way doesn’t make it the right way– or even a particularly good way. Choosing to be provincial and insular is a sure-fire path to ignorance. Learn how the other half lives. Get to know some developers who don’t live in the exact same world you do. Find out what tools they’re using, and why.

It is your duty to yourself, your company, your colleagues and most of all your career to keep your eyes on the alternatives. Don’t start to feel safe that you’ve made the best choice. Pick up other languages as they become of interest, use them in anger, understand why the Ruby way of doing something is different to the Java way, the .NET way and the Visual Basic way. Take that knowledge, absorb it, and re-use it in other languages, on other projects.

Unless you are happy to be a day coder, you need to do this. If you are serious about being a real programmer, and being all that you can be as a developer. You must have breadth. You must get away from the us-and-them, the religion, the I’ve chosen the right tool, yours sucks attitude.

You must understand programming as an art, not just the particular paintbrush that was shoved in your hand. If you don’t have the time or the passion to pick up and code in other languages, at least read blogs about them. Follow the design and issues that surround using that language. Keep yourself open to the new ideas.

It will make a huge difference

Popularity: 46% [?]

So now we have an Apache instance on a USB Key. Great. Can’t do much with it, other than brochureware, so our next step is to get PHP working.

Fortunately, the nice people at PHP provide Windows Binaries in a zip file. No messing with installers and then re-copying everything. Just go and grab the latest stable Windows Binary Zip of PHP from their downloads section. This can then just be extracted into /development/php.

I’ve gone for PHP5, later, I’ll show you a quick change to the portable environment I have that enables me to test Geeklog on PHP4 as well. (I use my portable environment for the stuff I do to Geeklog too, and that needs to support older PHP versions).

We have to edit a couple of files to get this to work on the key. Firstly, we need to configure the php.ini file to support our environment. Again, the first step here is to change paths to relative ones. Simple job of finding all the paths and editing them. Boring hey?

We then have to edit the httpd.conf file again to get it to load PHP:

LoadModule php5_module "/development/php/php5apache2.dll"  

addtype application/x-httpd-php .php .php4 .php5 .php3 .htm .inc .fire  

PHPIniDir "/development/php/php.ini"

Once that’s done, we can shut down and re-start. We also need a test php file to be sure whether or not the PHP instance is working, this is done by creating a new file called phpinfo.php, dropping it onto our web root and putting the following code into it:

<?php
phpinfo();
?>

We then visit that url in our browser: http://localhost:8080/phpinfo.php and should see a nice page telling us all about how our PHP instance is configured.

We don’t really want to leave things there, there are a number of further configuration options that it’s worth getting out of the way now, since we’re tuning for development not production and the sample distributed php.ini is a sensible startign point for a production server.

The main thing we need to turn back on is error reporting to screen and log. Both of runtime and startup errors. As we add and remove extensions and as we code, we need to know in real time that errors are happening:

display_errors = on
display_startup_errors = on
log_errors = on

The magic_quotes_gpc directive is an interesting one. It’s there to protect the not so great programmers from common attack vectors. I turn it off, always, and make sure that I work round the case where it’s on. This means I have to turn it on to test. But I keep it off for development. Geeklog (an open source project to which I contribute) works with it on or off. I write my applications to work with it in either state, but, I prefer to have it off, because it saves resource and I trust my code to protect my code better than the magic_quotes_gpc setting.

If you are not sure whether you want it on or off, find out what your production host has set, and use that.

With PHP5 you need to ensure that the mysql extension is loaded (remove the ; which has commented it out), and in preparation for our mobile MySQL on USB instance, we’re going to change the default MySQL port in the MySQL area of the ini file.

extension=php_mysql.dll

and

mysql.default_port = 3306

And that should be it, a fully working, development adjusted PHP5 in Apache instance set up and ready to go.

Popularity: 45% [?]

I’m fresh home from work, I’ve got a bit of time to myself as the kids have just gone to bed. I’ve got a number of choices as to what I do. I could watch TV. Watch a movie. Read a novel. Or something else. The top contenders on my list right now are to play a PC game (Ghost Recon: Advanced Warfighter) that I was hooked on before Christmas and haven’t had the time to play since then, or to write some software.

Today I found sux0r, it’s an RSS aggregator with a Baysean filter built in so it learns to categorise the posts I read. It’s pretty neat and with a bit of work I could have it trained to read all the BBC news feeds for me and only pass on the things I am interested in, so I don’t have to keep skipping the sports or international politics and can concentrate on UK news, tech, science and health.

It doesn’t quite work how I would like, so I’ve been glancing at the source and considering making some enhancements and submitting a patch back to the core project.

When I left for work this morning however, I faithfully promised that this evening would be dedicated to slacking off and doing something purely to relax. But all I want to do now is sit and hack away at an open source piece of software. To code. Which is my normal work.

I’m not alone, Eric Sink, the founder and a core developer at SourceGear posted this in his blog the other day:

Poker or Citizen Kane?:

A few weeks ago I saw an enticing little flash game on Reddit. It’s called Virus. After playing it just a couple of times, I wished that it had a solver. It took me 25 turns to win that round? How fast could a computer do it with 3 levels of look-ahead?

That night, the question was still nagging me. The kids are in bed. My wife turned in early. Should I pop in a DVD and watch X-Men 3 again? Or, I wonder how quickly I could clone that Flash game?

Eric choose to sit and re-invent a flash game to prove he could. And a few nights later, he ditched Citizen Kane in favour of writing a Poker hand comparison algorithm.

On the surface of it, this may seem like strange behaviour to non-programmers. We’re at home. We could be doing something for relaxation, instead we’re  working. But that’s the point. For a lot of real programmers, we do it because that’s what we love to do. Footballers play football because they love the sport. We code because we love to.

At the end of the day, working on your own problems for your own interest is a real buzz. It’s the problem solving. The challenge.

If you don’t get this, then you’re in the wrong job. People who aren’t enjoying it, aren’t relishing the challenge and wanting to stretch themselves can be programmers, but they won’t reach the same heights that someone who is driven to program can.

Popularity: 25% [?]

I’ve been doing a lot of DIY lately, after we had some building work done. Painting walls, laying new flooring, putting on new skirting boards, putting up new blinds and curtain rails. I’m not very practical, so my Father-in-Law is usually drafted in to help. One thing has become abundantly clear.

It’s all about having the right tools.

About 6 years ago when we moved into this house we turned the old owner’s kids bedroom into a grown up guest room. In the process we put coving up. This involves cutting stuff at 45 degree angles to make corners. When we did the coving, we used a Coving Mitre:

This is an odd shaped bit of plastic which can be layed at various positions on the coving to guide a hand-saw into cutting the right angle. It’s fiddly, and a pain in the ass to be honest. And because you are hand-sawing it’s hard work, and you can’t just nibble a couple of millimetres off. It was a long hard job.

A year or so later, when we put up some Dado Rail in another room my Father-in-Law had bought a Mitre Saw:

This makes it a lot easier to keep the saw in the right position and cut the angles. It clamps the wood in place. It made the job much faster. But it’s still impossible to cut a couple of Millimetres off a slightly too long piece of dado.

Last week, we put up skirting boards. Now my Father-in-Law has bought a Power Mitre Saw:

With this bitch you can do anything. It’s trivial to cut any angle in anything. You can trim a millimetre off the end of a bit of skirting in a second. It makes the job faster and easier.

When we were laying the flooring. My Father-in-Law cracked out his jigsaw and a Square (thing for getting right angles dead straight). Tools I don’t have, I’d have struggled with a big handsaw, a hacksaw and a steel ruler. And it would have taken ages and been crap.

It’s all about having the right tools.

Since this experience, I’ve decided. There is no point in doing a DIY chore without the right tools. And it’s no use going for the cheap-o option (the Coving Mitre) I need to get something decent. The Manual Mitre Saw would have been the best option, balance of cost and utility.

I’ve bought a cordless drill with a set of drill bits and screwdriver bits. I’ve bought a spirit level. I’ve bought a hacksaw and numerous other tools I’ve been doing without. The DIY I’ve been doing since has been much much more productive. I had to assemble some flatpack furniture yesterday. Normally a chore that takes hours and leaves me with hands sore from the screwing in of a million screws.

Yesterday, I used my cordless power drill and a couple of screw driver packs and had everything together in no time at all. Today, I put the curtains and blinds back up. Screwing them in took seconds, and I used the big spirit level with the built in ruler to make sure they’re level and centred on the window. And it took much less time than the blind I put up in our bedroom a couple of years ago, which wasn’t straight.

I still have to get my Father-in-Law round to do something if I’ve not done it before, and to show me what the right tools for the job are. But, my DIY is light years ahead of where it was 6 years ago.

It’s all about the having the right tools and knowing when to use which tool.

This isn’t just true of DIY. Take photography. When it comes to taking pictures of small children, you need the right camera. I’ve got an old 4 megapixel Nikon Coolpix 4300 at the moment. I bought it before my kids were born, and used to take pictures of landscapes on holiday, or us by the pool on holiday. Great camera, lots of control over what it does.

But it’s useless for taking pictures of kids. They don’t stay still looking cute for more than 2 seconds at a time, and the shutterlag on the Coolpix is about 3-4 seconds with a 10 second minimum delay between taking shots. It’s a useless tool for taking pictures of little kids.

It’s not just true of photography and DIY, it’s true of software engineering. Sure, you could write a full blown replacement for Microsoft Office using a command line compiler and notepad. But it would take orders of magnitude more effort than doing so using a rich IDE, powerful debugging tools and suites of standard components.

I know that I’ve said that coding is not like building a house. But, there are things they do share in common, such as the impact of trying to do a quality job in a decent time with the wrong tools.

It’s important that as a programmer, you have the right tools and you use them for the right job. Make sure that you are using the best programming editor for your language, if you aren’t, get the best or as near it as your budget will go. Make sure you have a debugger, profiler, lint tool, test tool. Make sure you have all the tools, and make sure you know how to use them. If you do, you’ll soon be producing better software faster.

If you aren’t, it’s not the right tool, or you’re not using it at the right stage.

Popularity: 34% [?]

Of course, the first part of your AMP instance to get working is the Apache part. A is the first letter of the alphabet, and you need Apache working before you can introduce PHP. And you may as well have AP working before trying to get MySQL working, since MySQL is there for your PHP application to talk to.

The problem I found with Apache was finding a reliable, trustworthy build of Apache for Windows in a non-installer format. I gave up in the end and grabbed the latest stable release of the 2.0.x line for Windows from the Apache downloads site here. You then have to run the installer and install it on a spare windows machine.

Once you have installed it, grab the contents of your install folder (Typically c:\program files\Apache Group\Apache\ or similar) and stick it into a folder on your USB Key. I went for \development\apache containing the contents of my Apache folder.

Once you’ve done this, you need to make some changes to your httpd.conf file. This can be found in the apache\config folder. Edit it in any text editor.

The main complication of using a USB key is that when you stick it in one PC, it will likely have a different drive letter assigned to it when you stick it in another PC. So, we need to make sure all paths are relative.

Now, firepages specifies using \\pdrive\\apache, I found this didn’t work. I used /development/apache/ and this worked fine. In fact, in all places I used Unix style path separators over Windows style path separators. And it all just worked.

In my httpd.conf I specified a number of virtual directories for each application I was working on, I’ll come to them when we first set up a test environment for evaluating software libraries. However, I followed Firepages example and set up a /development/applications/www directory for the server root. In there I maintain an index.html that lists all the things I have to access and works as a start page for me.

The other vital step, is to change the Listen directive to make Apache run on an obscure port. Because the machine you’re using might already have Apache or IIS running on port 80. I usually go for 8080.

Listen 8080

So, once we have Apache copied to our USB key, replaced all the absolute paths with relative Unix style paths to the USB key folders, changed the port Apache will run on and dropped a test index.html into the /development/applications/www folder, we can uninstall Apache from the host machine and leave it clean again.

Now we need to start Apache. I created a temporary start.bat that contained some basic stuff to do this:

/development/apache/bin/apache.exe

Once we run that up, we should have an Apache instance on port 8080. Just point a web browser at it. Congratulations, it’s a little baby portable Apache!

Popularity: 25% [?]

It doesn’t matter what you are doing, whether that is managing a web site that you run using an application such as Wordpress or writing your own application from scratch. You need a development environment. To run this site, I have my main webhosting with an installation of Wordpress. My Wordpress installation has a custom theme and I’ve installed a selection of plugins to get the functionality I require.

I did not prepare this work on my live webserver.

Since I set this site live, with Wordpress 2.0.5, two security releases (2.0.6 and 2.0.7) were released. Then Wordpress 2.1 was released, followed by three security updates. My site has now run six versions of code, it’s fully up to 2.1.3 (2.1.1 was compromised on the Wordpress site before I downloaded it and they advanced to 2.1.2 to avoid confusion).

But, when I did the upgrade work, I didn’t do it on the live site.

Once you have a site live with some software, you need to perform the upgrade on a copy of that site and refine the process so that when you do come to take your site down for the upgrade process it is a simple exercise that results in your site being live once more as soon as possible. Not leaving your blog down for days.

When you’re working on software, you want full control of the environment so you can debug and experiment to identify what the problems you are having are. You have to have a development environment.

Now, most web hosting is LAMP. Linux, Apache, MySQL and PHP. For things like Wordpress, Geeklog and the majority of web development, LAMP is the most available and most used platform. How do you go about having a LAMP environment to develop on? I would strongly suggest that you don’t want to use any hosting provider as your development environment. You may want a staging host, a subdomain that you perform the upgrade on before copying to your live environment. But the trial and error troubleshooting and testing phase should be on your Development Environment.

Now, if you’re not the kind of person who has a Linux box to hand that they can use for this, fear not, Apache runs anywhere, as does PHP and MySQL. You could install them on your Windows Vista/XP/2000/98/95 box (or even your Mac) and have an environment there. There are even bundled installers that give you the AMP portion all running in a few mouse-clicks.

But, I don’t use one machine. I have two laptops at home, and I could be on either, depending on what else I need to do and whether or not my wife wants to play games. I have a machine at work that I don’t want to have a copy of my development environment permanently set up on, and I don’t want the headache of keeping three environments in synch.

So, I had a bit of a Google to try and find a solution for a portable development environment. I’ve seen portableapps.com’s [1] available end user software and started looking for options for AMP development that can be extended to include Python, Ruby and other languages. I found a good article at firepages that was my starting point.

Since I first created my portable environment, portableapps.com released a portable XAMPP which would have saved me the effort. If you just need an AMP instance, I would investigate that. However; I want to understand my environment, know how it hangs together, feel confident playing with it and be installing Ruby and so forth. It’s also far more interesting to me, to build my own. Sad, but true.

I’m going to write a few articles on getting your AMP instance set up on your USB key, as I’ll need that environment to talk about evaluating software libraries and starting development. So this is going to briefly interrupt the flow of the Multiblog articles.

I decided on a simple structure for me USB key, I have a development folder in the root. This contains an Apache folder, a PHP folder, a MySQL folder and an Applications folder. Also in the root I have a Tools folder, containing installers for tools I use all the time, and a Downloads folder where I place the tar balls of things like Wordpress when I download them.

I then set out to start installing.

Popularity: 28% [?]

I’ve already posted an article about choosing a platform for your development. I missed a very important point, when choosing a language to develop in you also buy into the platform available to you, in this context, this means the third party libraries and supporting frameworks available to you. And as Jeff Atwood points out:

When you choose a language, like it or not, you’ve chosen a platform. And as Steve so patiently and calmly explained to all the Lisp enthusiasts, the platform around the language, more than the language itself, sets the tone for your development experience. The availability of common, popular libraries and the maturity of the development environment end up trumping any particular significance the language holds.

This was something I was planning to move on to talk about in more detail later. When you pick a language, you do need to look around at the choices of libraries available to you. PHP is lucky. It’s mature. There are a lot of libraries out there.

But, you must be very careful when confronted by such choice. Take a look at the options available for templating. Pear (a major source of libraries) have several implementations. There’s Smarty, and numerous other “just templating” libraries. The new Zend Framework also has a templating implementation.

There is a lot to choose from. Making the choice to go Pear::Flexy because that fits in with your use of Pear::DB, or to make use of the entire Zend Framework might be completely the wrong thing to do. You might want to create your own lightweight abstraction. Or go for something like SimpleT.

Picking a language with a small platform footprint can actually be better than picking a language with a large platform footprint.

But I’ll be talking about the costs associated with blindly using a library from the “PHP platform” for every project. When all you have is a hammer, everything looks like a nail. If you only have one type of hammer, that’s not worse than having a whole basket of different hammers.

Popularity: 58% [?]