 |
|
Projects |
Three benefits of digital schedulesFafner seems to believe that I enjoy digital gizmos for their own sake. Well, that's true to some extend, but the greater reason is that I'm a sucker for productivity improvements. Especially when they come with all the benefits inherent in digital schedules. While the list of benefits that digital schedules have over their paper-based counterparts undoubtedly is longer, I have here three reasons: Keeping omni schedulesIf you're doing Painless Software Schedules on OSX, think about doing them in the $29.99 OmniOutliner. It's incredibly easy and, unlike Spolsky's recommendation of $1,099 Microsoft Excel, let's you manage subtasks effortlessly. This leds to more detailed schedules, which in turn leds to more precise and reusable scheduling. Language applicabilityPHP Everywhere heralds the coming of an scripting era that will consume all: Looking down at scripting languages because it lacks this or that is short sighted because it is the now and the future of computing Questioning the applicability of a scripting language to solve all the programming problems of the world is anything but a label of failure. Languages and environments that tries to do everything will have little value to for anything. In London until MondayThe girl and I will depart for London at 19:30 tonight and not return until Monday morning. It'll be strictly a trip of pleasure, so I expect lavish spending, splendid eating, and enormous fun to be had. My Canon S30 has been charged and is ready to snap her sixty-something pictures before running low on battery, so I'll be sure to capture some Loud Visuals. Oh, and I'll try to prepare a few of my backlog arguments to the questions raised in the PHP vs Java debate while I'm away. The merits of strong typingLike most of the advanced OO features available to Java programmers, strong typing is often labeled superfluous by proponents of weakly typed languages, such as PHP. The argument is the same as that used against interfaces and abstract classes. It's unnecessary language fluff when all you need is common sense programming techniques. But the problem with "common sense" is that your idea of what that entrails is different than mine. In lack of language support, every programmer is forced to develop his own work-arounds. That makes it harder for programmers to work together (although coding standards can relieve this problem somewhat within a single organization). Anyway, here's two primary and one minor benefits inhabiting strong typing: Explicit statements of intent Strong typing is a communication tool for explicit statements of intent backed by the guard of compilation. Method signatures with strong typing tells you exactly what kind of input they expect and what kind of output they return. And the compiler doesn't allow you to break those rules. Weakly typing, on the other hand, requires you to be verbose about in- and output requirements in comments and vigilant about checking parameters manually. Error prevention by failing at compile time In weakly typed languages, you won't be alerted to programming errors, such as parsing a method a string when it expected an array, before a problem arises at runtime. That's expensively late. Overloading on type Imagine you have a method that's supposed to act in one way if it's passed an object and another if it's passed a string. The weakly typed solution is having a single method and manually checking the parameter type and then delegating the action. The strongly typed solution does all of that for you. Tricking Google into putting me firstNoting that I was ninth on a PHP vs Java googling has bought me the top spot. Lesson: Want to climb Google on a specific topic? Just talk about climbing and your current ranking. Effects of Apple evangelismAfter suffering months of intense Apple propaganda performed by yours truely, two of my study buddies caved in today and purchased iBooks (12" DVD models). One of them even got his older brother to buy one as well. Another study buddy is strongly considering getting one. When you create fantastic products and price them reasonably marketing can at times be had for free. Get IDEA 3.0 running on OS XIDEA 2.6 runs out of the box on OS X, but who wants that when the Windows and Linux people are enjoying the truckload of 3.0 features. Here's how to get IDEA 3.0 running on OS X:
Please note that IDEA on OS X use CTRL+C/V for copy'n'pasting (instead of COMMAND+C/V). This is especially frustrating to forget on the license screen. All other hotkeys are CTRL-based as well. Hopefully IntelliJ will conform to the standard Apple way of hotkeys in the future somehow. Shady methods in the battle for balanceMichael Kimsal (PHP app framework vendor) gives his blessing of means in justification of the end: ...certainly there's enough FUD from both Java and .NET folks about what PHP *CAN NOT* do that pieces like this are welcomed if only to attempt to present a bit of balance. I believe the exact opposite is true. Stooping to the level of FUD and adopting its shady tactics renders your argument untrustworthy. It robs it of usefulness for anything else than reinforcing misguided zealous pride in the pre-believers, who feel a need to be validated in their choice of language. Worse than merely being useless, it's actively damaging the attraction of attention from the .NET and Java camps. You could claim to care little about the opinion held in those camps of PHP, but it would be foolish. Now I'm going to walk out on a limp here, and likely draw the anger of my fellow expert PHP programmers. But I believe that the programmers in the J2EE and .NET camps are generally better educated, more experienced, and certainly larger in numbers than those of the PHP camp. (Note that I spoke of generalities. Some PHP programmers are better than some Java and .NET programmers.) This is a natural consequence of ease of use. PHP requires little programming prowess to get started. You don't have to know much about OOP, type-casting, class loaders, and what have you. You don't even have to compile. It's available at almost any webserver and integrates nicely with HTML from the get go. It's forgiving and informative in error. Hence, it's perfect for and attracts learners, kind to intermediates, and selectively useful for experts (as is most tools and languages). But I digress. The important thing is that I believe the world of PHP would do good by approaching Java and .NET in a more peaceful and non-confrontational manner. Show by execution the problems that can be solved simply with PHP -- not by vague and anecdotal comparison. It's okay to pick common problems, such as a Pet Store, but let the reader deduce his own comparison. It's more creditable. But I guess it depends on your motivation. If your need for validation in your language of choice is great then the road of spite is tempting. If your desire is to inspire, inform, or even persuade would-be PHP programmers, it certainly is not. (So it's language bashing and comparison week at Loud Thinking. May I recommend tuning in next week if this bores you endlessly?) Compensating productivityAdditional thoughts on compensating programmer productivity all collected from the Why some programmers are 2+ times more productive? thread on Joel on Software forum:
Ranked nine on PHP vs JavaGoogle quickly picks hot spots. The last few days of pro-ing and con-ing PHP vs Java on Loud Thinking has boasted me to the rank of nine on a "PHP vs Java" googling. Yay! Chosing a platform depending on criticalityRobert Byrne writes: Read your article on PHP vs. Java and you stated that PHP is good if the '...loss of data isn't fatal...'. I was wondering what you ment by that and if you could give an example of such a thing happening that would be great because I've never heard of such a thing. No problem, Robert. Different projects have different levels of criticality, which is basicly a way to define the cost of error in a given project. Different kinds of criticality Data loss on projects with low criticality functions in a way as a testing aid. When you loose data, there's a bug. It's not worth testing every minutia. In projects with medium criticality, such as an invoice system, the cost of error rises, but it's still possible to revert any problems that bugs create. When the system sends out a wrong invoice, the customer complains, the bug can be fixed, and a new invoice is send. Projects with medium criticality generally require you to restore the situation after fixing the bug. It's not enough to fix the bug and then say by-gones. In projects with high criticality, such credit card processing, it's very expensive to correct errors. If a bug causes every tenth transaction in the VISA processesing computer to round the numbers wrong, it'll be dfficult, time-consuming, and expensive to patch the wrong-doings of the bug. High criticality projects must pay great attention to avoiding bugs because they're so costly to correct. In projects with extreme criticality, such as nuclear reactor control systems, space shuttle launch programs, or pacemaker, bugs can be deadly. The user isn't likely to be around if a serious bug slips by. Projects dealing with life or dead criticality needs to pay an extreme amount of care to how they handle the development process. Few measures to prevent bugs from slipping by will be deemed too expensive. The above is largely based on principle four of the seven general design principles of methologies in Alistair Cockburn's Agile Software Picking a platform based on project criticality PHP certainly qualifies for projects of low criticality. Many projects have low criticality and hence will do good with PHP. It's more debatable when you move above low criticality. With strong care and forceful resolution, PHP can probably also serve projects of medium criticality. It'll require you to do a lot of work yourself, though, building mature testing frameworks that are already available in high quality for Java. In examining criticality, as in most every thing else, it's important to pick a platform that offers the right amount of bug prevention, detection, and correction at the right price. Arch-PHP apologist turns FUD-mongerIn yet another misguided attempt (read about the former) to prove that PHP is "The Perfect Choice" for all things web development, Harry Fuecks brings around his FUD-cannon and blasts away with the best of them. Attacking J2EE The reference implementation for JSP and servlets is the completely free and open source Tomcat server. And J2EE web-apps, especially if they're primarily JSP/Servlets-based, can easily be moved between the other open source and commercial implementations of the standard. Where's the vendor lock-in? It's arguably even easier to move a properly packaged J2EE web-application from one engine to another than it is to do the same with a PHP web-app. As the latter is easily affected by different settings in Apache configs and the Linux/Windows differences. Attacking Tomcat and JBoss Developing against J2EE provides both excellent and heavily supported open source platforms (Tomcat, Jetty, JBoss) along with a string of commercial alternatives (BEA's WebLogic, IBM's WebSphere, and more). These allegations are outrageous, untrue, and unfounded. But it gets worse. The most promising platform for J2EE development is both open source and free, so of course Fuecks can't let that slide without a good FUD-blast: "...taking a risk on open source projects like JBoss which have yet to prove their mettle". JBoss currently enjoys a succesful run in it's third major version with a fourth scheduled for Java One 2003. It had two million downloads in 2002. Where Fuecks highlights Yahoo as a major reference for PHP, JBoss can list McDonald's, Motorola, Nortel Networks, Worldcom, Dow Jones, and many more among its major references. Tomcat apparently also deserves a good punch, despite it's incredible free and open source offering: "And before you say it, would you really want to run your business on Tomcat?" Zealots from any language camp is bad news We don't need this. Fuecks, please stick to explaining how patterns can be used in PHP (a very interesting subject), and leave the blasting alone. |
