Friday, July 31, 2009

6 iPhone Apps for Web Developers

Perhaps the biggest reason for the staggering success of the iPhone is its thousands of applications that are available. iPhone apps ranges from games, productivity tools, entertainment programs but there are also apps that can be a great addition to a web developer’s toolbox. If you have an iPhone, here are some apps that you’ll find useful. Please note that the URLs for the applications below will automatically load the Apple Store within iTune.

Developer Notes

developernotesDeveloper Notes is an application built exclusively for software and web development community. It allows you to organize development tasks with ease. Each tasks can be assigned to a specific type like todo, fixme, idea with different tracking status like new, pending, on-hold or done. You can also prioritize tasks and set their due dates or move tasks between different versions. DeveloperNotes also comes with built-in email features that allows you to email tasks to yourself or your lead developer.

iCheatSheets

icheatsheetCheatSheets is for every seasoned developers that needs a quick refresher course. It is a free reference application that gives web developers quick reference to a variety of useful functions right at their finger tips. It has quick function and command references for most popular web technologies like ASP, PHP, HTML and also includes reference for topics like Mod Rewrite and Regular Expressions.

FTP on The Go

ftponthegoFTP on The Go is an FTP client for the iPhone with all features of a desktop FTP client. It allows you to fix your web site, and view files on your FTP server from anywhere. Other than the default FTP features like upload and download, it also support editing text file with its built-in editor. Its Find/Replace and Go To Line Number enables you to fix your codes faster. FTP on The Go can also store your files on your iPhone and you can view,edit or email any of the saved files.

DatabaseViewer

dbviewerDatabaseViewer is a commercial application with its price tagged at $19.99 - a little expensive for an iPhone application, in my opinion. It will allow you to view any database on your iPhone and you can synchronize data wirelessly. It support SQL select queries, filters and you can sort the fields. DatabaseViewer currently supports most of the popular databases like MS Access, SQL Server, MySQL, PostegreSQL and any other ODBC compliant database.

WorkTimer

worktimerWorkTimer is a time management application that allows you to track how long you’ve spent on various project so that you can eventually bill your client accordingly. This is pretty useful for web developers that works both from office and home and need a convenient way to track their hours. At the end of each month, you can email yourself (or anyone else) a monthly report of all the hours worked in different projects.

Source Viewer

soureviewerSource Viewer is a handy application that enables you to view a web site’s HTML source code - just as you would with the ‘view source’ option in your web browser. The source code of the web site is presented in an easy to read format with code highlighting feature. The best thing about this application is that it also collects all images and links (CSS links, JS links) from the source code and these can then be viewed separately.


Source : http://www.hotscripts.com/blog/iphone-apps-for-web-developers/

Posted by Indrajit at 6:43 PM 11 comments
Labels: , ,

Friday, July 3, 2009

10 Ways to Avoid Writing Crappy Code

1. Learn OOP and common OO principles

This is an absolute requirement. If you are still coding procedural, this is no small task. What are you waiting for?

1. Employ Test Driven Design

Code that is buggy or simply doesn't work at all can safely be considered "crappy code". TDD gives you the confidence that your code works, and the side effects force better and more flexible software design.
If you are not familiar with TDD yet, and this post has prompted you to try it, be warned: at first it will seem very cumbersome. What definitely will help is this piece of advice, which is at the core of Test Driven Design: don't write tests afterwards, write them first. Without going to much into the details, and somewhat simplified the general mantra is this: write a test first, make it work by writing the application code, refactor, write another test, make it work, refactor, etc etc. It's a cycle. The application code follows the test code, not the other way around.
I recommend PHPUnit. It has the most features and the largest adoption.

2. Refactor, refactor, refactor

Refactoring means "to improve the design of existing code". Making changes to code results in an increasing loss of quality of that code, this is known as "software decay". To battle this phenomenon, you have to constantly evaluate if the code hasn't lost it's quality, and look for opportunities to improve the design beyond it's original. But there's a catch. And it isn't the time that refactoring takes, if you do it properly you'll save those hours by having avoided software decay. It is the risk of change.
I can understand if you are hesitant to change code that works (at least for now). But this is where number two comes back into play: as long as you've written the right tests, you can make sure your changes don't break anything.

3. Simpler is better

Your mind should constantly be waging a battle between simplicity and flexibility. Avoid unnecessary complication.

4. Use Design Patterns

Design Patterns describe real world software design problem and solutions. Make sure you are familiar with them, buy some books. If you encounter a design problem that seems familiar take your trusty GoF and PoEAA from the shelf and look it up.

5. Don't Use Design Patterns

Once you are familiar with Design Patterns, or even just with the existence of them, it can be tempting to start sprinkling pattern implementations over your application code, just because you can. Don't. Remember a Design Pattern consists of a problem and one or more solutions to that problem. Until you have the problem, don't use the solution.

6. Accept the limitations of your language

Believe me, I know that as a programmer it is difficult to accept limitations on bending your code to your will, but trying to change the behaviour of PHP is not the solution. PHP has limitations, you'll have to live with them. If you try to "patch" them, chances are you will do more harm than good.

7. Pretend you are writing a book

It has been said that "code should be easy to read rather than easy to write". Maybe somebody else will need to understand your code at some stage. Maybe two years from now, you will revisit this code and need to re-learn it's inner workings.
Semantics, meaningful docblocks and clear execution flow are everything. Imagine reading an instruction manual without pictures, filled with meaningless abbreviations, and with the pages in arbitrary order, without page numbers. That's how someone, maybe you, will feel if you ignore this advice.

8. Peer Review

Believe it or not, you don't know everything and you aren't always right. Nobody is. Getting a "second opinion" can only improve the end result.

9. E_STRICT is your friend

Make sure your code runs properly with E_STRICT turned on. Although, if you have gotten this far, I don't think that will be a problem.

10. Create a distinction between "source code" and a "build"

Even though PHP is an interpreted language, this is an important distinction in my opinion, even though practically noone employs this in the PHP world. A build in PHP is a copy of (part of) the source code, which includes assets like HTML, CSS and JavaScript, and is stripped of anything not necessary for running the application. Maybe your build is a Phar file, or maybe you have combined some source files into a single file (like the guys at Doctrine do). Maybe you can provide different build of the same project to server different purposes..
How does this help you avoid crappy code? It allows you to have the source code and build differ, avoiding any compromises you might be tempted to make to facilitate runing or developing the application. Bonus points if you allow the user to choose between placing everything in the server document root or just a bootstrap and the static files.

There are various build tools available, personally I use PHPUnderControl, which is a patch for CruiseControl and gives you a variety of build server features. It uses Ant by default, but I also use Phing.
Posted by Indrajit at 9:39 PM 9 comments
Labels: , ,

Thursday, July 2, 2009

10 Signs of Crappy PHP Software

Like it or not, as a professional developer, sooner or later you are going to do some customising (if you are lucky, "extending") of existing software.
If you are not familiar with the software, it is good advice to look into it before accepting the job. I had to learn that the hard way. But how do you recognize crappy applications without getting knee deep into the code? 10 pointers to identify crappy PHP software quickly...
1. The software tries to reinvent the object model, or "fix" language features.

See if you can find a class called "Object". If you find it, it's a pretty clear indication that the author is in the business of trying to reinvent the object model (most commonly because of his own lacking understanding of OO). It is safe to assume that his "fixes" won't stop there. Unplug your phone and hide under your desk.
2. The code includes user defined global variables

A search in the code for "global" or "$GLOBALS" may reveal something like this:
global $database, $my, $mainframe;
The infamous global variable. If you can tell me what those last two variables contain you are either intimate with the software I pulled it from, or you're psychic. Unlimited bonus points if you can say what code has had it's claws on it before execution flow got to this point. In short, steer well clear.
3. Scattered HTML and SQL

Search for some common SQL and HTML strings. You should be able to determine very quickly whether these are appropriate places for HTML or SQL. If you find HTML and SQL in the same file, "crappyness" is most definitely confirmed.
4. Classes do too much

Find the 3 largest class files by bit size. Take a look at the class name. Does it indicate a distinct responsibility? Look at the methods. Are the tasks they perform closely related? If not, run away screaming.
5. Lots of properties are public or lots of properties are static

If lots of properties are declared "public static", triple your quote. If I have to explain why, maybe there's an open position on the development team of the software for you.
6. Multiple levels of inheritance

More than 2 levels inheritance should be avoided like the plague. I stake my life on the resulting objects having too much unrelated behaviour (ok, maybe not my life, but if you find a proper use of more than 2 levels of inheritance, I'll buy you a beer).
7. The authors try to use Design Patterns

Whether or not the authors have a clue is easily determined by searching for some of the most common design patters. Search the code base and/or documentation for "factory", "decorator", "strategy" etc. If present, you can pretty quickly determine whether the authors know their stuff or are trying to look interesting. That is, if you know how the code should look. If not, refuse to take the project until you do.
8. The software messes with the error level

Well written applications run fine at any error level. Searching the files for /error_level\(.*\)/ should do the trick. In case of hits, try replacing the value with E_STRICT. That's little more than a formality though.
9. In the code base, there is a directory called "core"

This is usually used as an excuse to have the whole application dependent on whatever is in there. Despite the appeal of the term (it does make the contents sound pretty cool and important), defining a "core" is a sign of bad design.
10. The software uses it's own template language.

Be afraid. Very afraid. These guys are definitely in the business of reinventing the wheel. Ignore this warning and you will find yourself spending the better part of a day simulating a "for" loop.



Posted by Indrajit at 11:58 PM 7 comments
Labels: ,
Subscribe to: Posts (Atom)