Josh Sharp - web application development.

I think it's safe to say that a lot of us think big. We have some great ideas, and given the chance, would definitely be the next Google. Without a doubt.

Well, perhaps that's a bit far from the truth. But there are a lot of ideas out there which are never going to be realised. Some of them are undoubtedly rubbish, but think of all those really nifty, practical services or products that are never going to see the light of day because we just don't have the time or the money.

Good ideas

I have a couple of ideas that I think could work quite nicely. The big one, that's been kicking around for quite a while now, is a social network (groan) based around a local community. Yes, it's been done, yes, there's a million reasons why it wouldn't work, but damn — I really like this idea. There's more to it than that brief overview, of course, and I think it's those little extras that would make it work, but at the moment it's nothing more than a registered domain and the wild dreams of little developer in Australia. The odds aren't good.

There's just no time

The problem, I think, is that big ideas need big resources. Where are those resources supposed to come from? If you run your own business, and don't need to fill every business hour with actually making money, then you're probably in the best position to do something about your idea. Or if you're already successful, you have the resources to follow that idea and (hopefully) make yourself even more money. But for all of us who don't have that sort of time or money to spare, what are we supposed to do?

What to do with all these ideas then?

Ideas without implementation aren't worth much. The only advantage we have over Average Joe user is that we can implement this stuff ourselves. Being a developer means you're already in a better position than the majority of the community because you have the skills to realise your idea.

But as previously mentioned, if you only have a piddling amount of time to offer, then the amount you can actually implement isn't going to be much.

By your powers combined, I am Captain Startup

Wouldn't it be great if there was a big group of developers who believed in an idea so much that they were willing to each put that little bit of time towards a common idea? Do you think it would work? I have been toying with this idea as a way for people like us to use the power of the internet to realise these big ideas that are just a bit out of reach. Obviously massive ideas wouldn't work, but a social application or a simple service might actually come together.

As an example:

Users submit their idea to this site, where it joins the pool of ideas. Ideas get voted on and the best, say, ten ideas get picked. Other users (developers and designers and what-not) with relevant skills join the groups and work together on this common idea, each receiving a proportional amount of the profit once the idea gets off the ground. The best way for it to work, of course, would be if a massive amount of people got involved and the average developer had to create perhaps only a couple of functions.

Leveraging the power of Web 2.0 user-generated content into actually creating a startup.

Of course, all the usual caveats for user-generated content apply: it wouldn't all be good content, people are lazy anyway, and the finished product may not be something worth striving for anyway. But perhaps it's worth a go.

Thoughts please

Do you think this would work? Would you be interested? Or do you have some feedback on a better way this sort of approach could be run?

I personally would love to be involved in this sort of thing if the idea was great and the amount of time I had to commit wasn't massive :)

I'm really looking for community feedback here guys, so help me out with a comment, and maybe my little idea of realising other big ideas could actually come to life.

Just a quick tip — hopefully this will help anyone having the same issue as I was. Our development server at work runs Ubuntu 6.10 (using the default Ubuntu LAMP setup), and this setup happens to use Apache 2, with PHP as an Apache module (rather than a CGI extension, or whatever).

Now this default setup doesn't include some fairly standard PHP extensions like cURL and the GD libraries — but working out how to get these included caused me no end of trouble. I didn't want to recompile PHP, but didn't understand why adding a reference to libgd.so was giving me the error that it wasn't a valid PHP library. And surprise surprise, it's not; you need the PHP bindings. So for those who are in the same situation and don't want to recompile PHP, but need those extensions, there's actually a very simple solution that was incredibly hard to find on the web.

You can just install the packages from the repository.

So if you're a GUI person, you can use Synaptic and search for "php5" to retrieve the list of available modules. Or if you prefer the terminal, it's as easy as typing sudo apt-get install php5-gd or sudo apt-get install php5-curl.

I wish somebody had told me that.

This one has always had me wondering how everyone else did it, so I figured what better way to find out than to put up a quick poll.

So it's fairly straightforward: in your code, do you have a database wrapper class with abstracted functions like query(), or do you call mysql_query() (or equivalent) directly from your code?

Leave a comment below if you're outraged that I even had to ask.

For those of you who aren't aware, Apache provides a very nifty module called mod_rewrite which (can you guess?) lets you rewrite URLs, with or without the end-client knowing. As I've mentioned before, this can be pretty handy. No longer must your URLs look like domain.com/folder/subfolder/file.php?some_id=23. Instead you can present your users with pretty URLs like domain.com/area/action/this_is_a_unique_identifier, and anything along those lines.

There are two main reasons why you'd want to do this:

• Accessibility for users: your users don't need to remember long GET parameters, or file extensions for that matter. URLs can become more relevant to the content and to the user.
• Accessibility for search engines: yes, this will help you quite a lot with The Google. You now have a far bigger chance to put your relevant keywords into the URL, which is one of the places they count the most.

So let's have a look at how you'd do this.

Keep reading

Well after the last post on this topic, it seems like frameworks are one of those topics that divide the PHP community. You either love them or you think developers who use them are weak, girly-men who probably can't open jars without help and only use frameworks because they don't understand how to write good, simple code. Me, I am that girly-man — but I do know how to write good code, thankyouverymuch.

The thing about writing a framework yourself is that it gives you the best possible understanding of how it works. There is not one part of that framework that you don't have to really think about as you code. "Do I really need this?", you think, or perhaps more likely, "I don't understand how that works — I'll leave it out".

While I coded I learnt about URL rewriting, dynamic methods, abstract classes (well, how to use them in PHP anyway) and a bit about form state persistence and the like. And the result is that I know exactly how to put my framework to best use for whatever the project may be. It may not be a good framework, but it's mine.

Keep reading

Now, if you're an open-source developer, you probably break into a sweat whenever working with Microsoft products is mentioned. Apache will always beat IIS and MySQL (or PostgreSQL) will reign supreme over SQL Server, despite those naysayers who worship at the temple of Steve Ballmer (I hear they chant "developers, developers, developers" and dance in religious ecstasy). And so it is with me. I knew that SQL Server had all those extras like stored procedures, user-defined functions and views — which MySQL didn't until recently — but I preferred the non-evil side of the force.

Turns out MySQL offers some little extras after all. Little things like the LIMIT clause, which allows you to define a range of results to be returned. This function is absolutely invaluable in paging data, but... in versions of SQL Server older than 2005, there's just nothing similar. The closest is the TOP clause, which returns the first X amount of rows, but does not allow you to specify a starting index.

What follows is a journey of strength and courage, of overcoming adversity, of sticking with SQL Server even when all seems hopeless. This is the story of attempting to page data returned from SQL Server 2000.

Keep reading

There's a reason why PHP is growing rapidly as a server-side scripting language — it's very easy to pick up. Many functions are included without needing any sort of namespace importing, and you don't even have to write OO code if you don't want to. Variables are weakly typed and the syntax is fairly familiar.

But PHP's ease of use is also its downfall. Because there are less restrictions on the structure of the code you write, it's much easier to write bad code. But there is a solution: use a framework.

PHP frameworks like CakePHP, CodeIgniter and the Zend Framework (which I wasn't too taken with) provide a solid structure for your code whilst also offering some extra functionality that would be much harder to replicate on its own. It's important to note, too, the frameworks mentioned follow the MVC pattern, which is fairly common and what I'll talk about below — some of these benefits will apply to other patterns as well, but not all.

Of course, if you're not taken with any of the packages above you can also write your own framework, which I've done and will talk about in the next few posts. But for now, let's have a look at the common benefits of a framework.

Keep reading

I wanted to share with you a couple of points I learnt while at the conference. Andrew Downie and Grant Focas presented an excellent talk on JavaScript and accessibility, and what they said certainly came as a surprise (and a bit of a relief) to me. It basically boils down to this:

It's okay to use JavaScript in your pages as long as you observe some basic rules.

I had never really thought about it up until now, I must admit, as most of the web applications I write are internal and thus only need to conform to the company's guidelines. But Grant and Andrew reassured us that screen readers have come a long way in the last few years, and can handle dynamic content and functionality fairly well. Their view is the onus is mostly on the manufacturers of the software to keep up with recent developments in web technology that the rest of us already use. This certainly sounds good to me.

There are, however, a couple of things you should be doing if you want your sites to be as accessible as possible.

Keep reading