Thursday, March 27, 2008
Lines Of Code - Dispelling The Myths
LOC As A Metric of Accomplishment or Project Size
This one is old, and most experienced programmers now officially reject it outright. But still, I feel it worth repeating: The number of LOC you write in a single day is worthless as a metric of what you accomplished that day. After all- If someone wrote a 1000 line class in a single day, and you wrote the same class in 500 lines (and maybe tossed in a little extra functionality while you were at it), who was more productive?
As a metric of project size, it makes a little more sense, but just barely- The Wikipedia article on LOC mentions that “Many useful comparisons involve only the order of magnitude of lines of code in a project.” That at least makes a little sense. One can reasonably assume that the same set of programmers, using the same language, will be able to accomplish more with 10000 lines of code than with 1000.
Editors' note: The lines below may be wrapped and on more than the lines stated due to our template.
Ambiguity: Too Many Ways To Count
The next issue is this: How do you COUNT lines of code? That same Wikipedia article linked above has an interesting example:
for (i=0; i < 100; ++i) printf("hello"); /* How many lines of code is this? */ How many lines is that? One for the line? Two for logical seperation of forloop and print statement? What if you wrap the line in curly braces, one on each line, and move the comment to it’s own line, so it looks more like for (i=0; i < 100; ++i) { /* How many lines of code is this? */ printf("hello"); } Did you see that? I just took one line of code, and turned it into 5! Things get so much more confusing than stylistic issues like this, though. What about libraries? What about frameworks? Jeff Atwood wrote a post a couple of months ago wherein he mentioned that the original version of Basecamp had been written in only 600 lines of code. Given that Basecamp was written using Ruby on Rails, which handles all sorts of crazy things for you, I think the more honest metric would have to be the 600 lines of basecamp, plus however large the RoR framework is, plus the code RoR generated for them when they started the project. Money says it’s more than 600 lines. I’ll give you another example. Currently, the amount of code I’ve written for Migratr is 5000 lines and change. However, Migratr uses FlickrNet, a popular .NET library for interacting with the Flickr API. FlickrNet, if you download the source, is more than 12,371 lines of code (according to the unix util “wc”). I’ve also incorporated a few other libraries, all of which are linked in Migratr’s “about” page. Why? Because I didn’t want to write those 12,000 lines. Someone already had, and they did a fantastic job of it, and I didn’t see any point in re-inventing the wheel. So the total code involved in Migratr is, at this point, more than 17,000 lines. I’ve written 5,000 of them, and I’m the sole developer of Migratr. But I wouldn’t dream of saying “I built this application that interacts with a whole slew of online photo services and migrates all your photos and does all this neat stuff, and it was only 5,000 lines!” No. MY contribution was 5000 lines, but Migratr depends on a lot more than that. The point being, where do you draw the line? Is Migratr a 5000+ LOC project? or 17,000+? Do you only count LOC if you have access to the source of the library you’re using? Do you only count the code written for your specific project? Could I export Migratr’s backend as a library and let someone write public void migrate(String filepath) { ImportFromSource(Services.Flickr, filepath); exportToDestination(Services.SmugMug, filepath); } Did you see that? My whole project was just replaced! Some twerp in a garage somewhere just re-wrote Migratr in 5 lines of code! It doesn’t matter that it depended on my 5,000 line library, which depends on (among others) 12,000 lines of the Flickrnet library. You only saw 5 lines. It was only 5 lines. But clearly, since 5,000 is more than 5, I can at least say that I was more productive. The relationship between line count and bug count only goes so far The idea that “Less lines of code mean less bugs” is some sort of universal absolute is the biggest of all the LOC myths. In a desperate effort to nullify your “oh snap, time for a flamewar” reflex, I’m going to add a couple of disclaimers before I get into this. Any reference I make to a programming language is not an attack on that programming language, just an attack on the abuse of that language. Also, I realize that reducing the amount of code required for a specific task can help reduce the bug count, but only so far. I’m saying there’s a limit to this. Here’s the line I want to draw for you. Reducing the code involved in a task will only help reduce the bug count IF THE PROCESS MAKES THE CODE MORE READABLE. Past that, you’re probably creating lines of code that do more than one thing per line, and thus increasing the number of bugs possible per line of code. Perl programmers are especially frightening in this regard. I really love PERL and use it instead of shell scripting languages such as BASH whenever possible, but there’s something in the PERL culture that demands it’s programmers to try and do something in the fewest number of characters possible. There’s even a name for this as a sport- It’s referred to as “Perl Golf”. Really quick, can you tell me what this is? -pl s!.!y$IVCXL426(-:$XLMCDIVX$dfor$$_.=5x$&*8%29628; $$$_=$_!egfor-4e3..y/iul-}/-$+ /%s''$';*_=eval I’ll give you a hint- It’s not a cat walking across my keyboard. If that was your first guess, though, we’re at least on the same page. This was the winning entry in a game of Perl Golf: The problem was to write a Roman Numeral Calculator in the fewest characters possible. Submissions can be found here. Now, this is an amazing piece of code. The person who wrote it is clearly very skilled. The fact that Perl makes code like that possible is pretty impressive. The problem here is that people write code like this outside of PERL golf, and think to themselves, “it’s only one line, so it must have fewer bugs than a 50 line solution”. Really? Because if I had to debug one, I’d have definitely gone with the 50 line solution. And don’t tell me that that one line of code worked on the first, second, or 5th try. The 50+ line solutions might have, but not that catwalk. Writing unmaintanable code does not reduce the bug count for a project. A friend of mine coined a term for code like that- “Write-Only Code”- a takeoff on the permissions you can set with chmod. Think about it: Readable, writeable, and executable. Shouldn’t code be all three? Another quick example: (0/:l)(_+_) The first time I saw this snippet, I thought someone was, via emoticons, trying to re-enact the facial expression one wore when seeing “Goatse” for the first time. It’s not actually a story told by emoticon. It’s a piece of scala code that sums the elements in a list. And I just don’t see it as having been easier to write than a forloop. It’s definitely not as maintainable. This piece of code, actually, prompted a conversation with a friend about holding a “code or emoticon” contest, but we really couldn’t come up with any serious contenders to this one. Maybe some Perl Golfers could throw their hat in the ring? I want to state too, that for this section, I’m well aware that I didn’t provide buggy one-liners. I provided working one-liners. This is because I was trying to emphasize, the point isn’t if it works or not. The point is if you can tell by looking at it what it should do. If you can’t, it’s unmaintainable. If it’s unmaintanable, then even if it works the first time, it’ll produce a slew of bugs as soon as anyone tries to modify it. So, in essence - stop paying attention to Lines of Code. They’re impossible to count in any useful way. They’re a crappy metric of project size or personal accomplishment. And they don’t control how many bugs your code has. You do. cheers Aurobindo
The hard truth regarding employee happiness
In the last ten years I have held a total of seven “career” positions, and I have been in business for myself. I have been a copywriter, design technologist, Web developer, creative consultant, interface developer and I am currently employed as a software engineer. I have worked anywhere from eight- to twenty-hour days, and my pay grade has varied by as much as $50k. Without asking, you would presume I am never happy with my work.
Contrasting opinions
There are several explanations for the contrast after taking a longer look at our situations. The first of which involves the economic uncertainty that appears to plague my generation. Guaranteed pensions and stock options are a thing of the past, and if the economy in the US (at the time of writing this) tells us anything, no one can even promise you a steady paycheck. The reality is that the marketplace, no matter the market, is simply different now than it was forty years ago. The fact that two of the positions I formerly held were lost due to bankruptcy and downsizing are testimonies to that fact.
The second view is that the generation gap is significant enough to warrant the difference. Our attitudes regarding career accomplishments are vastly at odds because there is almost forty years between us. A sense of entitlement is much more prevalent in the workforce today, and there is no room for growth at a company that will not meet certain demands. So many have received untold wealth with little effort, that it is now becoming an intrinsic ideal among all employees. Without that get-rich-quick potential, is it worth it to invest a lifetime at any corporation?
The third view is that I am simply different than my father. My aspirations, my view on family and friends, what I consider achievement, how I arrive at success — all of these cause me to pursue career interests with a unique perspective. It might be that my happiness is directly related to each of these personality traits, and there is nothing by anyone else’s doing other than my own that will cause me to be happy. Because these beliefs and values shift, it may cause a shift in how I view each employer.
The complexity is daunting
When you begin to understand the complexity of the problem, you realize how difficult it can be for an employer to make the vast majority of employees happy. Being in the business of information technology, I can tell you that there is also a cultural rift between this field and any other, which creates an even more complex (and at times volatile) atmosphere. Employee happiness is the coup de grĂ¢ce for management and HR, so much so that outlandish attempts are made to find the perfect non-compensatory benefit.
I find it interesting that there are so many possibilities, and I thought it would be helpful to list just a few I have stumbled across in my day. You can get on-site daycare, sales kickers, game rooms, chair massages, dual (or triple) monitors, exercise machines and showers, retail discounts, paid training, free lunches, concierge service, access to on-staff nutritionists, accountants, and computer technicians, after-work socials, holiday parties, shuttle service, and the list continues.
This begs the question, why are all those now necessary to employee happiness? Could it be that each and every one of those is quite possibly smoke and mirrors, hiding the hard truth that most businesses can no longer guarantee what was once permanent, and therefore must replace the permanency with temporal niceties? Stop to think about this for one moment before you dismiss this as one man’s pessimistic outlook. Was my father happy with his job primarily because there was at least a small sense of certainty with respect to the nature of his employment?
My dad could be fairly certain that if he did a good job, came into work on time, was respectful to his peers, and was responsible for his actions, that he would receive everything promised to him on the day of his job interview. That is not to say there was never a mistake made by management, but the likelihood that he would get passed over for his hard work and dedication was less of a concern. The relationship between himself and the post office was symbiotic, and it was understood that the livelihood of both employee and employer were dependent on both doing exactly as promised.
What to do about it
If that is the case, then I want to explore the alternatives, and what I consider to be the prerequisites that all employers should adhere to in order to create an atmosphere conducive to employee happiness. This exercise is not as complicated or scientific as you might think, but these three requirements certainly require some forethought when you are job hunting.
1.) Fair wages for a fair day’s work
The question running through your mind is undoubtedly, how do you decide what is fair? This is not that difficult to determine, and it involves little research. The first point to consider though is that fair does not involve your life situation. Debt, a mortgage, hobbies, private school for the kids — none of these matter when you consider your future salary. The fact is, you have experience, a job history, skills, education, and a mean average cost of living. These will help to determine what is fair.
Start by reviewing open positions that you are qualified for in comparable cities across the country. For instance, eliminate sweeping generalizations about pay grade by avoiding comparisons like Detroit to San Fransisco, or Atlanta to New York. Average the salary ranges for matches on similar job descriptions, as well as your experience, and you will find out quickly what is fair. Then, find employers who will stick by these same standards.
A manager once explained to me why several employees were granted a senior title, when it was obviously unwarranted based upon their performance. He said that they were great negotiators, and because HR matched the salary to the title, the two then became inseparable. Many did not consider that fair, including the manager. He spent a considerable amount of time trying to level the playing field for current and new employees, and was completely honest about it. This is the type of fairness that you will need to seek.
2.) Honesty in all things before and after
Four months before the Internet bubble burst I was employed with an interactive agency building dot com startups. Every day my entire department would come into the office and surf the Internet, chat away the week over coffee, and enjoy free lunches. After a couple months a coworker and I began discussing the economic feasibility of supporting five hundred employees who had no billable hours to a single client. In our frustration we were open about our doubts, and before long management caught wind of our nay saying.
Of course, we were reassured like everyone else at the time, that all was well, and this was merely a bump in the road. The sales pipeline was full, and we would be busy again soon. Not too long after the daily free lunches moved to Friday, and then stopped altogether. At our next quarterly meeting we were each given a copy of the now infamous book Who Moved My Cheese, a patronizing tale about survival in the corporate world written at a third-grade level. The message was clear, but management would not budge. No one was going to lose their job.
I quickly became the town crier, bemoaning our demise, and telling other employees they had better update their resumes. I only received back blank stares. Tired of the whole ordeal our manager walked into our next department meeting and candidly taped two pieces of paper up on the wall. He drew a smiley face on one, and a sad face on the other. He pointed to the sad face, and said, “You can be one of two people. If this is you, then we don’t want you here.” I typed up my letter of resignation. Two weeks later everyone lost their job. The company declared bankruptcy.
Some businesses still operate under the same dishonest practices. They are unwilling to share financial data, information about why employees are here one day and gone the next, and they lack a vision that truly drives the organization past status quo. The piece of paper taped to the wall is an adequate illustration — it only makes employees sad.
3.) Respect for the common man
The final requirement for employee happiness might be considered altruistic by some, and an unquantifiable goal. Everyone views respect differently, and how can a thousand, or even ten employees come to a single consensus on what it means to be respected. My answer to that is one word — roles. I am not writing about status, or even responsibility, but more about purpose. Respect means giving each employee a role, or purpose, and communicating exactly what that should mean to them.
Not only must the employee own the role, but a business must allow them to define that role, and grant them the authority to work within the bounds of that role. I am reminded often of the TV series The Office when I ponder roles. Dwight K. Schrute, a valued employee at Dunder Mifflin, so desires to have authority bestowed upon him as Assistant Regional Manager. However, he is undermined constantly by his boss Michael Scott, who informs him incessantly he is only Assistant to the Regional Manager.
Although no one enjoys being compared to Dwight, relating to him is quite easy. He is given token responsibilities as a method of appeasement, but no authority to carry it out. He is asked to perform duties not in line with his position, and he is reprimanded for taking initiative in matters he has no business attending to at the Scranton branch. This constant limbo is nauseating to employees in the real world, and it quickly leads to anxiety and uncertainty.
The only thing worse is being expected to fill someone else’s role. When an employee is asked to pull double-duty because a fellow coworker is unable to perform, it can cause a great deal of resentment. In some situations, being shorthanded in one department will cause an overlap in roles. For a short time this might be acceptable, but if resources remain tight long term, then an employer should make amends for the blurred line between roles.
Too easy
Do these three suggestions appear too simple-minded? Could it really be all that easy for employers to keep employees happy by adhering to those principles? There really is only one way to tell, and that is to try and instill those organizational values if you are a manager, and demand those rights as an employee. Openly discussing the issues, and pushing for change in performance reviews and even during interviews will be the only way to help bring about a positive outcome.
Java is losing the battle for the modern Web. Can the JVM save the vendors?
This was the typical reaction dynamic languages would get from the Java community. There were many believable reasons for why these languages, especially the ones gaining fame on top of the LAMP stack, would not last. However, one thing which the Java community ignored for many years was the radical shift to the Web, not only for media and e-commerce Web sites but for a large majority of business applications including CRM, ERP, reporting, document management, etc… As a result Java EE (then called J2EE) was not built with the Web in mind but rather focused on enterprise integration, transaction management and other back-end processing. While Java EE has long supported Web development with servlets and JSP the companies driving the standards ignored the RESTful nature of the Web and rather continued to drive a general purpose platform.
In parallel, the LAMP-like architecture built on top of the C language’s eco-system of libraries and tools started becoming the most popular platform for developing Web applications. This trend grew in the second half of the 90s and with a recession following the burst of the .com bubble it greatly accelerated due to the lower TCO that the LAMP solutions had to offer. While there are a variety of dynamic languages which make up the LAMP development and deployment paradigm, the most ubiquitous language has been PHP. As a result of PHP being domain specific to the Web it has been shaped in a way which makes it fit the Web paradigm like a glove. By focusing on solving the common Web patterns quickly and easily it holds the biggest market share on the Web. In two separate surveys of one of the most popular Ajax Web sites, the Ajaxian.com, around 50% of Rich Internet Applications developers are using PHP. The trend has also been significantly accelerated as a result of the many popular PHP packages including Wordpress, Drupal, mediaWiki, osCommerce, SugarCRM, and more…
When it became apparent to the large Java vendors that the Web paradigm was being built and innovated without Java they started backing a variety of both standards and non-standards driven Java Web application frameworks which promised to adapt Java to the Web. Such frameworks included Java Server Faces, Struts, Spring MVC and others. Some of these frameworks have been more successful than others but in general none of them managed to resolve one of Java’s main pain points on the Web. The strict typing and overly complex architecture of Java applications meant longer development times and a need for more skilled engineers in order to push Java applications into the market, i.e. Java’s TCO on the Web was unsatisfactory.
In the meanwhile the large Java vendors were trying to hold the stick at both ends. On one hand trying to be part of the Web paradigm shift and on the other hand protecting their multi-billion dollar businesses built on the Java language. Even the pervasiveness of dynamic languages in the Web space didn’t change the vendor’s behavior significantly. The big change came when Microsoft aggressively pursued a multi-language runtime environment for the .NET platform. Not only did they support C# and VB on their virtual machine but they worked with their developer community to add a large amount of languages including Cobol, Eiffel, Ruby, Python, and others. As dynamic languages continued to grow to the point where industry analysts started defining categories (e.g. Forrester Research on dynamic languages) Microsoft continued to leverage their common runtime which was designed from the get go to support multiple languages.
As mentioned earlier the de-facto standard implementations of the successful dynamic languages including PHP, Perl, Python and Ruby are all written in C and leverage the breadth and depth of the eco-system of C libraries. As community driven projects these languages do not have a specification nor is their development hindered by corporate bureaucracy. On the contrary, these languages are being developed by their users who have only one end goal – get the job done, quickly… As a result the languages are constantly evolving often adding significant enhancements in minor releases. With the rapid changes in how modern Web applications are being built and deployed this agile nature is a must-have to keep up with the latest trends.
In addition, the LAMP deployment paradigm has significant advantages. By featuring a multi-process architecture, faults in the Web Server and dynamic language software will typically not lead to sites going down. While one process may crash all other processes serving Web requests will continue running. This is in contrast to multi-threaded environments like the JVM (Java Virtual Machine, Java’s execution environment) where software faults including crashes and deadlocks will typically lead to system down situations. In addition, the ability to recycle processes after a set time will prevent memory leaks and memory fragmentation, two common software memory problems, from degrading the system efficiency over time. Another key advantage LAMP developers enjoy is the easy deployment paradigm. Software updates can easily and incrementally be pushed out to LAMP servers without requiring prolonged build and packaging processes. While this may lead to unorthodox and sometimes too lax of a process, when done correctly it makes the lives of the developers and the operations personnel much easier.
While LAMP’s growth was fueled by many of these development and deployment advantages, the Java vendors were stuck with the JVM which was very closely aligned to the Java language and had little support for targeting multiple languages. Instead of shifting towards a loosely coupled model of LAMP technology and Java technology in order to deliver the best of both worlds to their customers, most hesitated to lose control over the customer’s workload and entered an arms race to deliver dynamic languages on top of the JVM. With Microsoft on one side and the Java competitors on the other, each vendor set out to develop their own dynamic languages strategy.
Today Sun is investing in JRuby (Ruby) and Jython (Python) support for its Java EE solution; the IBM Websphere group has realized the ineffectiveness of the Java EE platform for running modern Web workloads and has invested heavily in Project Zero which aims to make big blue a Web 2.0 player and initially delivers support for Groovy and PHP; BEA has also had some incubation projects going but with the upcoming sale to Oracle it is unclear whether any of those efforts will materialize. Project Zero’s Chief Architect is one of the first IBMers to admit in public that Java today can be considered as a system language and is not desirable for building RESTful Web applications which is Project Zero’s goal (slide #4 of the presentation- see slide #11 to see how a simple “Hello, World” in Java compares to dynamic languages like Groovy and PHP). It has taken over 10 years for the Java stronghold to admit Java’s poor ROI on the Web and with the current recession it is likely that many Java customers are going to be making more informed investments. As a result there will be considerable rise in uptake of dynamic languages. Similar to the mainframe Java is heavily entrenched in enterprise IT and business-critical applications and is therefore not going away. That said for fueling modern Web applications the Java language will likely see a steep decline in market share.
The question to be asked is whether the non-Microsoft Web market will buy into the JVM implementations of dynamic languages or whether they will move to the LAMP stack which hosts the de-facto standards for the most popular languages. While I believe there will be customers who are attracted to the JVM implementations especially the ones who are heavily influenced by their relationships with the Java companies, the majority of the market is going to prefer to go down the route of the LAMP stack. Reasons include:
- The popular dynamic languages are all backed by very vibrant developer communities and are constantly evolving and adapting. The JVM ports of these languages will always lag behind the community driven de-facto standards implementation and therefore compatibility will be an issue. This is very similar to the problems the Mono community has in keeping up with .NET and this is even after help they get from Microsoft.
- The JVM was not originally designed to host dynamic languages. For the foreseeable future the vendors will have significant challenges in keeping up with real-world use-cases. While they may show good performance in synthetic benchmarks such as for loops where JVMs are often superior in real world scenarios they will likely be impaired due to the dynamic nature of these languages which include closures, indirect method calls and a significant amount of type juggling. See an example of how JRuby compares to Ruby’s current C implementation. Also, we have to consider whether it’s truly in the hardware vendor’s interest to pursue the most optimized runtimes. With open-source community driven technologies the answer is clear.
- The scalability requirements of the modern Web will require an increasing amount of processing density on the Web tier. C-based architectures are much more likely to be able to deliver the highest possible density by most efficiently interfacing with the operating system primitives and by delivering efficient, small foot print architectures. Such examples include high-performance Web Servers such as lighttpd, Zeus, IIS 7; high-performance caching systems such as memcached which is used by some of the largest Web sites including Facebook; and other performance critical subsystems such as memory management.
- Multi-core systems work very well with the LAMP stack’s multi-process paradigm. With the chip industry now focusing primarily on multi-core as opposed to hyper-threading technology, the benefits of multi-threaded environments such as the JVM are not substantially realized on today’s hardware. Instead the multi-process paradigm delivers more stability and reliability.
- Due to its simplicity, the LAMP stack delivers a very low barrier to entry for developers while still delivering the scalability of large scale production systems such as Yahoo! and Facebook.
In conclusion, it is becoming clear that dynamic languages are going to increasingly become the standard for Web development. Microsoft and the Java vendors have all recognized this trend and are now aggressively pursuing solutions on top of their software stacks. However, as the core dynamic language communities thrive outside of the .NET CLR and Java JVM software stacks the vendors will be in a challenging position if they solely depend on the uphill battle of cloning the successful dynamic languages onto their software stacks. Some vendors are aware of this challenge and have built hybrid strategies which also aim to deliver the de-facto standard dynamic languages to their customers even if they don’t have full synergy with their solution stack, this includes Microsoft’s investment in making PHP work with their solution stack and Sun’s initial attempts to deliver native Ruby and PHP implementations to their customer base. I believe that while the JVM approach to dynamic languages may appeal to some Java customers it will never be able to catch up with the broader open-source movement around native dynamic languages implementations. The JVM dynamic languages implementations will not be enough for the Java vendors to catch up and they will need to embrace the native de-facto standard community driven dynamic languages.
Microsoft working with Eclipse - EclipseCon 2008
Helping out with Identity Management in Higgins and SWT on Windows
In summary, the announcements are that Microsoft will continue to help the Eclipse Higgins project out more when it comes to CardSpace interoperability and also help out with WPF performance enhancements for SWT (this means making it easier and/or better to use Windows native look and feel in Eclipse-built applications).
What’s clear from the question I asked Sam during the keynote is that there’s not going to be any Microsoft employees committing code to Eclipse. Instead, Microsoft will simply help others do this. This matches the usual model of interacting with open source - through third parties instead of directly - that I’ve come to expect from Microsoft, and it’s just fine, really. This is the kind of thing we should probably expect ongoing from all parts of Microsoft when working with open source.
The motivation here from Microsoft is the one we’ve heard over the past two years with partnerships with JBoss, SugarCRM, and other open source stacks that find themselves running on Windows. The point is, as long as you’re paying for the Microsoft platform - Windows, ActiveDirectory, or even the System Center stuff on the optimistic end - Microsoft is OK with you running open source on top of it. The promise of announcements like this and the ones in the past is that Microsoft will even spend time and money to make sure they work well.
From the Eclipse angle, it seems all gravy: getting help to optimize Eclipse UI’s on Windows will make the Eclipse GUI and GUIs built off it better and getting Microsoft “on board” with the bus of identity management ambitions of Higgins is great. The Eclipse folks I talked with seemed happy.
Lingering Mistrust Warranted?
As I tell all people, the biggest challenge for Microsoft with things like this is the long trek to getting to the benefit of the doubt from the open source crowd. Your analyst here tends to fall into this camp having fallen victim to quick of skimming of the recent interop memo from Microsoft and missing the key “not for commercial use” clause, having to rely on Dalibor to point it out (thanks!).
Indeed, as I IM’ed Paul Krill during the keynote:
An analyst was skeptical of Microsoft’s efforts. “We need some more fine print to make sure there’s not any weird clauses like that ‘not for commercial use’ stuff in the Microsoft interop memo,” from a few weeks ago, said analyst Michael Cote of RedMonk.
That is, if there’s some fine-print to be found, it deserves some scrutiny. But, to be fair here, there doesn’t seem to be much room or reason for fine-print wizardry here. Still, as mentioned I’ve missed the boat there in the past: the RedMonk community is usually good at hunting down the bad apples in the fine print barrel.
Assuming the work is as straight forward as it looks on the tin, it seems all good to me. While there’s not code committing here, the point is that Microsoft would be committing to help out Eclipse by way of answering questions and running tests. They’ll answer the phone when Eclipse calls up, not only answering the questions, but doing even more with lab resources like testing and assuring that interop works. If things are that simple, then sure, good job all around.
8 Questions You Should Ask on Every Project
This concept of questioning what you are doing is especially relevant to the arena of web design, which is notorious (in my experience) for having few — if any — criteria for success and for not asking these questions.
The questions Jason lists are:
1. Why are we doing this?
2. What problem are we solving?
3. Is this actually useful?
4. Are we adding value?
5. Will this change behavior?
6. Is there an easier way?
7. What's the opportunity cost?
8. Is it really worth it?
Some of these questions seem pretty obvious, but I can assure you that more often than not they have not been asked. Or, if they've been asked they have not been fully answered.
I can recall plenty of web projects where the criteria for success was "getting it done."
Often I've been able to tie the project back to relevant business objectives by writing a creative brief and forcing the client to clearly outline the goals of the project.
However, there have been times — when I've been brought on to a project after it's started and the deadline is looming — where the direction has been set and you don't have time to ask these questions.
All you can do is get the web site/application live within the timeframe and do the best you can. It's pretty disheartening.
So, the next time you start a web project, or are brought into one that's already in progress, or are well into a project that you have started, ask some or all of these questions — it might not be too late to change tack.
All-Out Code Edit War: What's the best Web-developer's Code Editor out there?
10) | So first there’s Vim. Vim stands for ‘VI – Improved’, as it’s a GNU remake of the old UNIX ‘VI’ text editor. Vim is primarily for Linux/Unix systems. Vim looks like something you’d see on a green-and-white CRT monitor in front of a programmer in the movie Superman 2. It’s straight from the 80s (pure ASCII text-based love), and furthermore it doesn’t even have a funky keyboard based ASCII faux-gui like nano or emacs, it’s keyboard shortcuts and commands or BUST. Vim is said by it’s die-hard followers to be the hands-down fastest way to write code, but only after you’ve spent 15 years figuring out what all the keyboard shortcuts and commands do. For example, the command for save+quit is ’:wq!’. If that’s not intuitive to you, it’s because you’re a NORMAL PERSON. Personally I will never understand the legions of vim-geeks. Why not ‘ctrl+s’?? Anyway, vim is actually pretty handy sometimes, besides just being a classic:
PROS:
|
9) | Visual Studio .NET is a Microsoft development environment for just about everything. Really! It does C/C+/C#/VisualBasic/VC+ and the kitchen sink. Hey… But none of those are web languages! Well, exactly. THIS IS NOT A WEB DEVELOPMENT ENVIRONMENT. When I walk into a coffee shop and I’m like “Oh, you’re a web developer?” and I look at their screen and see them editing ASP code in MSVS.net I just break out laughing. This is not just because of my true hate for ASP (maybe a little..), but also because it took MS until 2008 to get good “Intellisense” (code completion) for Javascript and CSS. How can you even call this a web development environment? So besides that, you can do code-bookmarks (which I kind of like, when I’m editing C!), tabbed-browsing, syntax highlighting, and all the other standard code-edit stuff. If you’re working on an ASP project you can Debug your applications line-by-line.
There are no real advantages to using this IDE: the documentation is TERRIBLE, the community is non-existent compared to OS alternatives and their respective IDEs (like the PHP & Ruby languages), the interface (and the configuration) is complex and ugly. Furthermore, there’s no such thing as Open Source when it comes to Microsoft, so naturally this (VS.NET 2008) costs like $1200 bucks for the full version, and guess what? It’s terrible to use with MySQL, so if you want the Full Integrated MS package you get MSSQL 2008, and then you’re out another 1000+ bucks. “Sounds Great! Where do I sign up?” SLAP, read below to find out why I think this IDE is terrible crap. PROS:
|
8) | Next we have Midnight Commander. Midnight Commander really doesn’t count as an ‘IDE’ per se (like vim), however it is a pretty powerful tool that can (to be sure) meet the same ends when it comes to web development. So, MC is like a futuristic editor/file-manager, except it’s stuck in ascii mode. MC features a full on menu system and ASCII GUI with mouse support (look out vim-heads)!! Not only a file manager, MC can use one of it’s panes to edit code with it’s built-in editor ‘mcedit’ which features syntax highlighting for most common languages. With mcedit you can also use the mouse to edit text too, which is (always) an eternally handy feature. MC also boasts the ability to look directly into common archive types (such as .zip, .tar, or even .rpm) as though they were directories on the system. It can also act as an FTP client, which is pretty handy for those of us who work in PHP (or without versioning software in general). One thing I find pretty neat about midnight commander is it’s level of customize-ability, the user can change the panes to do pretty much whatever they want, I like that. it’s also filled with keyboard shortcuts (obviously, being an ASCII app) that can make life much faster when it comes to editing/renaming/moving around files, and flipping about it’s panes. To put icing on this already bloated cake, MC now has an HTTP filesystem browsing plugin, meaning you can use HTTP virtual directories just like a mounted drive. That’s pretty freakin’ cool.
PROS:
|
7) | Dreamweaver is primarily a windows IDE, which does absolutely everything, and mostly it does it all really freakin’ bad. For the record I absolutely hate Dreamweaver, as well as most other adobe web-development solutions. However, it’s a major player in the IDE game and I want my own chance to back up my good reasons to hate this. Basically DW can handle the most non-experienced web developers and give them something super-graphical to work with. DW even will write pre-made JS scripts for would-be complex elements of a site that require some Javascript Know-how. Unfortunately it’ll give you disgustingly complex markup (and scripts) and instead of using would-be simple css techniques to do image-swap operations. It exports a full-on image pre-loader script, which is a crap approach. Actually, most things DW does are the ‘crap’ approach. It also attempts to incorporate server-side logic into it’s graphical frontend a-la ColdFusion, which I just couldn’t hate more (as a non-coldFusion developer). The reason it’s on my list is because it’s actually got a decent text editor built into it, and if you’re only using it to edit text, it’ll serve you right. It gives you tabbed code browsing, easy to use find operations, and syntax highlighting, as well as some more handy features. One thing I specifically like about DW is the ability to search for a string in just one directory of a massive project EASILY. Also, it doesn’t use java, so once it’s all started and initialized it runs pretty smoothly and quickly. Another thing I like about the find function is that you can split the main edit window into panes and use them for what you’d like. I’m usually splitting between the find in project pane and the code editor.
PROS:
|
6) | Zend Studio a PHP IDE (for Windows, Mac & Linux) that comes from the very same people who developed php. Zend sports some pretty cool features when it comes down to PHP. It’s the only IDE for PHP I’ve ever seen that introduces a line debugger; being able to do breakpoints with PHP and examining data (can) save HEAPS of time. Being a modern editor it’s got most of what you’d expect from an IDE in 2008: It’s got tabbed file browsing, an easy way to do a ‘find-in-project’, groovy text-editing keyboard shortcuts, etc. Also, it sports database-view which is compatible with all kinds of db types, including MSSQL and MySQL. If you’re using phpmyadmin to view your db all the time and find it tedious at times, this is actually a pretty great tool. Why is it all the way up here at #7? Well, for one thing it’s written in Java, and it’s totally clunky and *slow because of it. It’s definitely a heavyweight and seemingly without all the features to really back up it’s memory footprint. Furthermore, if you’re like me you’ve probably long-since left PHP in the dust for Ruby or something else (i.e. something better), and Zend isn’t going to be very helpful anymore..
PROS:
|
5) | NetBeans IDE is Awesome. Firstly it’s FREE, which I suppose considering all the other GNU/GPL compliant projects listed on this page isn’t that surprising, but it’s still pretty cool for a fully-featured IDE like this one. NetBeans supports a lot of languages, and (being an OpenSource Project) sports a load of plugins. Since I’m mainly a ruby developer, i have to go off about this, but it also features a load of ruby/rails developing tools in it’s base version, which is pretty impressive considering how much other stuff it’s doing. Netbeans has pretty great rails code-completion stuff, as well as a regexp helper (which is pretty cool). It also features GUI’d up rails file/generation for MVC stuff, which does make it that much easier. Another thing I find pretty groovy is a gem installation manager, so no more comparing the output of sudo gem list to figure out what’s going on. Unfortunately (and this doesn’t bother a lot of people, but it bothers me), you must create a project before you really start working. Other editors/IDEs are currently realizing that developers frequently need to hop around and edit things on the FS, and this task is greatly complicated more rigid when one must make a project and add files to that project, etc. I know I’ve talked a load about it’s Rails features, but netBeans also has a very impressive feature-portfolio when it comes to PHP and even more-so for Java and C/C++ development.
PROS:
|
4) | Eclipse Is probably the most well-put-together open-source IDE I’ve ever encountered for Linux. Firstly, ECLIPSE IS FREE, which is awesome for how big of a product it really is. Also, this IDE is written in Java (and as such it’s on OSX Win and Lin), however unlike most Java applications Eclipse uses the SWT libraries for it’s widgets (not swing) and because of this it really does seem to work much better and less clunky. I mean a lot of things by ‘clunky’ by the way, but swing has a serious tendency to redraw every widget all the time, and it makes this awful flicker. Also it just runs significantly slower than the native OS’s windowing toolkits (MFC, GWT, etc.).. Anyway, Eclipse draws all of it’s power from an EXTENSIVE list of eclipse plugins. These plugins will basically allow you to bend eclipse to your will. Needless to say, with the right plugins eclipse can do EVERYTHING I’ve listed for every editor above, and probably even more. That’s hip. It can integrate with database systems (mssql, mysql, sqlite, etc), it supports syntax highlighting for any language you can find an eclipse package for (most languages), and it can be customized to be a SUPREME web environment. Eclipse also supports line-break debugging of PHP applications. Also (I really like this) the Mylyn extension integrates your Bugzilla account at work to your IDE, letting you manage bugzilla tasks straight from the IDE. That’s freakin’ cool. It also has full (FULL) ruby-on-rails support, which I’ll explain in #5.
PROS:
|
3) | Aptana Is a really unique eclipse-based ide. If your work centers around Javascript and DHTML techniques and you don’t want to pay for your IDE, this is the one for you. Aptana seems to be an IDE geared towards DHTML development. Being ‘Eclipse-based’ means that aptana is really an extension to eclipse (i.e. on a linux system you install eclipse first and upgrade it to “Aptana”). Aptana also comes stand-alone if you don’t want to get eclipse first (although it will still be using the eclipse core). This IDE features everything you need to develop Ajax applications. Firstly, you’ve got code-complete operations for javascript, CSS, and other DHTML favorites. Also (with the RadRails plugin) you get code-completion on rails objects and methods with inferenced typing. Not only is that tech stuff, but it’s also slick. You also get heaps of rails-specific features with RadRails (which I have to talk about, as a rails developer). You get integrated testing in the IDE, which of course helps you run your tests as much as you SHOULD be when you’re developing. You get an integrated “script/console”, which is (admit it) totally awesome. Aptana also handily gives you a view of your whole HD instead of requiring you to start an Aptana project to contain all files in, although you do still have that option. I really like that. Being a very current environment, Aptana also supports current trends in javascript like Prototype syntax (as well as Dojo and Mochkit).
Okay, so a little off the subject of the IDE for a second, Aptana also has one grand trick up it’s sleeve. Aptana is also producing Jaxter which (and I know this will hurt your head at first) really introduces Server-Side Javascript. Check out an awesome example of this here. I was pretty impressed! Jaxter basically does away with the rigid concept of a client end doing strictly managed data trading via ajax. Instead, Jaxter makes it possible for the client and the server to both run the same javascript, thus making the information exchange much more transparent. Surely when both age a bit there will be VERY unique things one will be able to do with Aptana and Jaxter together. PROS:
|
2) | Komodo IDE is an awesome IDE from ActiveState. I had the good fortune of running across the ActiveState guys doing a demo of this at RailsConf in Portland Oregon where I got a free Komodo 4.1 CD from them. This IDE is a ruby guy’s dream, I like the interface in this one a lot. Firstly, it’s got awesome (and undoable) find/replace-in-project features. Secondly (this is important), when editing PHP projects since there’s so many files I really like to use the arrow keys to quickly navigate through the file tree. Specifically I like it when you can press L/R to expand/contract a folder, and for some reason in Eclipse this only scrolls the file-browse pane (who would need that on the arrows?). Anyway, I really like Komodo handles this.
Also, Komodo is built on the mozilla engine, which (I’m sure) made it easy for ActiveState to provide full-on browser integration for debugging Ajax/JS applications. That’s really cool, other IDE DOM inspectors/debuggers usually can’t hold a candle to this. Since Komodo is a Rails IDE specifically, you can do some serious debugging, INCLUDING using script/console WHILE breakpoint debugging from inside the IDE. That’s pretty awesome. It’s got a Unit::Test interface, which is pretty cool, but really it’s just a widget to run rake, which is a bit crap because rSpec is gaining ground really fast on the rails TDD scene, and so far this has no support for it. Furthermore, Komodo IDE doesn’t have too big of a memory footprint, and starts pretty quickly. HOWEVER, if you only want an awesome editor with full code-edit 2008 features (even code completion), it ships with KomodoEdit, which is basically all the text-edit glory of Komodo IDE, but without the IDE. KomodoEdit takes about a second to start on a fast machine. Did I mention it’s available for Windows, Linux, and OSX? PROS:
|
1) | TextMate is my favorite editor and the one that I use, released for OSX (only). Textmate built this site! Textmate really isn’t (per-se) an IDE, but it’s the most full-featured editor EVER. Basically, the interface wins me over here. Firstly, to open a project all you do is drag the folder (in finder) to the textmate icon in the Dock, and it immediately gives you the code editor window and a file-navigation slider page. It’s very lightweight; textmate takes about 1 second to start. Despite it’s many features, it even appears lightweight, which I really like. It’s extremely non-obtrusive in comparison to the other entries listed on this page, which I really like. Furthermore, you can just type ‘mate So, besides all that, textmate is very useful for quickly finding things in files, or around a massive project. When I press (apple)-T I get a ‘find file in project’ dialog, which updates each time I press a new letter key, whittling down to the final file I’m looking for. It does this based on matched characters, and not squential matches (although that does seem to also carry weight). Point being you don’t even have to spell (or remember) the filename correctly and usually you’ll always get the right one. Also, these lists (if you don’t type anything) list the last files you’ve opened with the dialog, so many times you can just use the ‘last 10 files’ list to select what you need without typing anything. When you’re in a large monolithic file you can use the ‘Go to Symbol’ dialog (ctrl+shift+t) and you get a list of all your classes and all the methods/class variables inside of it (all indented properly), which you can go directly to in the code by clicking. You also get a find/replace in file and find/replace-in-project with ctrl+f and ctrl+shift+f (I like how related operations have related key shortcuts). Of course, regexp is there when needed. Code completion is partially supported in ruby (for now) but in C, Java, and PHP and a host of other supported TM languages the code-completion function is fully implemented. I’ve got the Ruby bundle checked out from the Macromates SVN (because I can do that), and the new generation of ruby code completion is looking sharp! Also you can run your tests AND debug your code (macromates has added ruby-debug to the TextMate mix) from inside TextMate, which encompasses most of what I ever need to do with a full-on IDE in terms of Ruby. And one more thing. If you hold alt your text selector turns into a crosshair with which you can select blocks of text vertically or horizontally and edit them vertically. This even includes otherwise incredibly complicated block-cut/copy/paste operations. This saves me just heaps of time. One last note: this is the only editor I’ve found so far that has HAML syntax highlighting. Textmate costs about $30. PROS:
|
Must have tools for a Java Developer
Apart from your favourite IDE, I feel, a Java Developer might be very productive with the following tools (in no particular order):
- Firefox (Do I need to say anything about it?)
- Apache Ant (Not needed, if you use NetBeans. NetBeans has got bundled ant)
- JEdit (Mainly for it’s wide range of plugins. I use it’s LogViewer and HexViewer plugin frequently. Also it has got excellent syntax highlighting for your properties file, java files, nsis scripts etc)
- Subversion Version Control System(Got excellent integration with NetBeans and Eclipse. You must consider it atleast for your personal development.) You can read more about installing subversion here.
- Apache Tomcat (The ubiquitous servlet container.)
- Glassfish (The best open source application server, at the moment. Thanks RedHat for making JBoss AS development sluggish. JBoss AS users are waiting for nearly 1 1/2 years for the 5.0 release.)
- Hudson (The fastest growing continuous integration server. This can be an excellent add-on to your ant/maven based build process). You can read more about hudson here.
- Java Service Wrapper (An excellent product to launch your java applications as a windows service)
- CheckStyle/PMD (Excellent code coverage tools to make your source code more maintainable)
- JASYPT (Excellent cryptography library to encrypt/decrypt your passwords, files etc.)
- Apache Commons Library (Contains almost all the utility classes you will ever need. Kindly check this project before writing your own utility classes)
- JUDE Community (An excellent free UML modelling tool. You must definitely give it a try. It’s lightweight and it’s very simple to use.)
- MySQL (The most popular open source database at the moment)
Did anybody say that I forgot to add Google as well
What else do you use? It will be of great use to the community if you can share about your experience as well.
Note: I tend not to include frameworks like Spring, JSF, Wicket etc.. Because you can see these frameworks too are highly subjective and a major reason for lots of flamewars. And that’s the reason why I didn’t mention any IDE as well. Whatever IDE or framework you use, it’s very likely that you might need the above mentioned “tools” except a few like database/application server, whose choice are mostly defined by a particular organization.
You should read this article in the perspective of “tools needed for your personal java development”. Because there are “lots” of factors involved in your work environment regarding the selection of tools.
And lastly, this is my humble suggestion only. So if you find your favourite tool missing, don’t get panic.Cheers Aurobindo :)