Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 472

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 487

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 494

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 530

Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/edelabar/ on line 594

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/edelabar/ on line 594

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /home/edelabar/ on line 594

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /home/edelabar/ on line 594

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/edelabar/ on line 611

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /home/edelabar/ on line 705

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /home/edelabar/ on line 705

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /home/edelabar/ on line 705

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /home/edelabar/ on line 705

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /home/edelabar/ on line 728

Strict Standards: Redefining already defined constructor for class wpdb in /home/edelabar/ on line 306

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 103

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /home/edelabar/ on line 425

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /home/edelabar/ on line 623

Strict Standards: Redefining already defined constructor for class WP_Dependencies in /home/edelabar/ on line 15

Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/edelabar/ on line 311
Eric DeLabar

Sometimes You Should Just Say No!

Every time I read a new post on Andy Rutledge’s blog Design View I feel the need to comment. Andy has made the decision to not allow comments on his site so instead I’ll comment here. The latest article on Design View is about Pre-Bid Discussions, in it Andy explains how his company turned down a $50/60k project because they could not see the project succeeding according to their terms. For the fact that he turns down projects for integrity reasons, I applaud him! As far as the article, his analysis and process are insightful and I’d love to be able to use them, but for now I’d just like to expand on them.

I would like to add two questions to Andy’s list of five, and I’ll continue with his format of stating the questions and then coming back to them, so numbered for reference:

  1. Am I or is my team able to develop with the technology stack?
  2. Would I invest my own money in this project?

As Andy laid out in his article, these are questions that should be asked during the pre-bid discussion. There is nothing worse than blindly responding to an RFQ and winning the job only to find out that the client does not want somebody to help them implement a solution, they want somebody to blindly do their bidding without question. But I digress, ladies and gentlemen, the questions.

6. Am I or is my team able to develop with the desired technology stack?

I have seen this question extract chunks of flesh more times than I can count. Most programmers will tell you that programming is programming and the difference between languages is small enough that given a few weeks a real programmer can learn any language. I’ve said it myself, and I thoroughly believe it. However, I’d much rather have the end results from a programmer who’s an expert in a language or framework than a programmer that only learned it a few weeks ago. Think about these questions when discussing the technology stack:

  • What version of X Technology are you using?
  • Do you have internal coding standards to which we’ll need to adhere?
  • Has something been developed and deployed to this platform before?
  • Will your team be interacting with our code directly?
  • Will we be interacting with your team’s code directly?

These questions are more technical than Andy’s, but they’re vital for determining the overall scope of a project which is necessary for placing a bid. Software versions can make huge differences. I whole-heartedly agree with coding standards, but if the standards say no open source or external code you may be up a creek if you rely heavily on Jakarta Commons. Is this stack even possible? Sure, the bigwig sales guy said a heterogeneous solution of Company A’s ORM and Company B’s DB and Company C’s development environment would work, but have you seen it and can you get support for it when it fails? Finally, if you’re co-programming this project with the company, will they be changing your code? Will you be changing theirs? What does their programming team think of bringing in outsiders? How long will it take them to make a code change that you need and who’s responsible for making up that time? Think about who’s making the rules, who’s following them, and who’s enforcing them.

7. Would I invest my own money in this project?

Nothing will kill the morale of your team like working on a project they think is doomed to fail. I really hate to tell you to judge somebody else’s ideas, and 9-chances-out-of-10 I’d take the client that has a few million in VC-backing, but sometimes it just doesn’t make sense. This especially comes true when the sales pitch for the idea starts with: “It’s like some-other-app but…” Let’s all face it, twitter is a huge surprise and everybody loves it, but that does not mean “It’s like twitter but instead of other users subscribing to your tweets you get to publish your tweets to the people you want to see them,” will ever make billions. If they’re not the first, the free, or the best, let somebody else implement the failure. I guess this is a bit of a sore spot for me personally, but ignoring that, here’s some questions to ask:

  • Have you done focus groups or would you like us to help you do them to support the feasibility of this project?
  • How do you intend to monetize this idea?
  • How do you intend to build your user base or generate buzz about this idea?
  • What happens if the users adapt your system for some other use beyond or in contrast to your initial plans?
  • What is your reason for starting this project?
  • What is your goal, how do you define success for this project?

No audience, no plans to obtain an audience, and no way to make money are surefire signs for failure. If you still like the idea and you think you can help, at least make sure you get paid up front. The next few really don’t have right or wrong answers, but the foresight to know that the agility to adapt might be necessary is a good thing to have. As for reasons, you might want to get out your moral compass, if it’s for world domination, drug trafficking, destroying the ozone layer or patent trolling you may not want your name attached to it as the implementor. Finally, it’s good to know the client has a plan, how can you define the success of this project if they can’t.

My Main Point

Like Andy, I’m definitely saying that if you establish your own rules up front it will make it easier to say no to a job no matter how big or easy is might seem. Unlike Andy I will say that I understand the necessity to bend these rules on occasion to at least keep your team busy, if not productive.

But let me stress the “on occasion” part. It is not good to be the bargain basement whore of web application design. Your reputation can mean the difference between finding jobs and having them find you; or playing the part of the expert-consultant or errand-boy slave. Your portfolio, client-list and case studies can speak worlds about your company, but not if every client that’s ever worked with you has gone out of business or insists on not being on the list. Even a big-name client means nothing if they’re using some propriety or ill-conceived tech-stack your team would rather quit their job than use.

Think about it. Make your choice. Reread the title.

Jack of Even More Trades, Master of Even Less?

I’ve been at my current employer for over four years. We do Java-based web application development. Four short years ago, this industry was a different world. Web 2.0 didn’t exist. Ajax was a cleaning product. A website that only worked in IE 6 was good enough for most clients. Tables were a viable solution of any HTML markup problem, and the semantic web had something to do with a children’s book about a pig. Four short years ago we were the Jacks of all web-application development and we had it mastered.

When I started here our tech stack was pretty small, we wrote J2EE applications and we deployed them to WebSphere Application Server (WAS). We wrote these applications using WebSphere Studio Application Developer (WSAD) using a home-brew framework of GoF patterns and JSP scriptlets. JSTL was just entering the scene and JavaScript was a dreaded task used only for fly-overs and submitting forms with more than one possible action. CSS was used for changing font sizes and a table-based layout was not just the norm, it was expected. SEO was using alt attributes on your image element. You could learn this stack in a few weeks while studying for your SCJP cert, be a useful resource on small tasks in a month, and be the lead architect of major subsystems in six. A true master in six short months.

For this career, at least here, a B.S. in computer science was required (emphasis on the BS), but that just got you through the door. Everything else you needed to know you learned in the first six months to a year. You learned how to read code. You learned how to search Google for solutions. You learned how to search the CVS repository for the way we solved it last time for some other client. More importantly you learned how to learn.

Now, here we are four years later, the Web has reached its next version, and discussion has started on the one after that. Our tech stack is now outlined on a four-page spreadsheet. Home-brew pattern implementations are now a thing of the past. We have Spring for IoC and MVC on the middle tier. Hibernate, JPA, iBatis and JDBC for DB persistence, plus web services and SOA, and even a little JCR. The view is now at least JSP/JSTL, sometimes Velocity, sometimes even JSF, and they just generate the markup. CSS is a part of life, tables are for data only, and we sometimes write more JavaScript for a project than we do Java. We deploy to WAS, WAS CE (geronimo), Tomcat, JBoss, WebLogic, and insanely configured combinations of them all. We develop in Eclipse, Rational Application Developer, IntelliJ IDEA, and we might even try NetBeans. We test on IE 6 and 7, Firefox and Safari, we test with and without JavaScript. We advise clients on search engine marketing, social networking, tag clouds, URL rewriting, XML sitemaps, feeds, microformats, link building, link bait, and duplicate content, not to mention semantic HTML with a clean structure and accessible markup. We do automated unit and integration tests, performance testing, code coverage reports, and are discussing a continuous build server.

Our training program remains basically the same. We simply throw more words at the newbies and hope they’ll take the initiative to at least look them up. Now they can write unit test and perform AJAX calls, but they don’t know how to methodically test a simple web form submission. They avoid SQL, especially on a terminal. They regularly check broken code into CVS or foobar a code-sync to the point that work has to stop for hours to clean it up. They have even mastered the ability to create unit tests that provide 100% code coverage but don’t actually test that anything works. They know enough about the technology stack to be literally dangerous.

How do you train people for Web 2.0? I could write and teach a year-long course that covers all of the technologies, but I’m beginning to doubt it would matter, and they’d never take me off of the projects that actually make money to teach it for that long. I’m sad to say, but I don’t think the problem is the training, I think it’s the mentality. You went through college, you know how to write code. If you know how to learn, the size of the tech-stack shouldn’t matter. The tech-stack makes you life easier if you learn how to use it. You don’t learn Web 2.0 from a book or a class, you learn it by living it. You want to design web apps, where’s your website? At least tell me about your idea for the next killer web-app. You want to write code? Show me. What open-source project(s) do you contribute to? Write an awesomely bad and ironic implementation of the fizz-buzz problem and explain to me with a smile on your face why you did it. Tell me why Joel is your new religious leader, how Zeldman and Meyer are your preferred deities. Try and convince me that the CSS Zen Garden is bad, or voice your opinion on the IE 8 version-targetting debate. Show me you have passion. I’m tired of code-monkeys, show me you’re a rock star.

*Smashes keyboard, steps down off the soap box, walks off stage.*

But seriously, is it that much different? We still have the same GoF patterns, we just use somebody else’s named, branded, and marketed implementation. Web 2.0 is just doing the web the right way, it’s using now-established best practices that were still being invented four years ago. We can still be the masters of all things java web-app development, we just need to continue reading and learning. So how do we make the next generation of masters? To that I say you can’t. You need to find them. You need to find the people that have the pre-bubble mentality, the people with the passion and drive to love this stuff. Those people can be groomed to masters simply by showing them where to look. As for the others? Teach them how to use source control. Teach them how to test a web-form. Teach them just enough html to make something look the way the client wants it to in IE. After that, let them work on the .Net and JSF drag-and-drop component-based development. Let them build boring intranet applications that can run on IE 6 until the ancient machines they were designed for finally die. Let them stagnate in the Web 1.0 mentality, and when they’re obsolete, get them out of the way.

JavaOne 2008 – Day 4

Day four at JavaOne was a bit of a blur due to it’s smaller population and shorter duration. Add that to the fact that I caught a red-eye back home and didn’t sleep all day on Saturday, and Friday and Saturday became one large day. But I digress.

Regretfully I left my notes at the office today, so check back tomorrow for the details on the sessions that belong in this paragraph. But until then…

The best part of Friday was the General Session demo of the Livescribe Pulse smartpen. The Pulse is a regular pen with an IR camera attached that scans a special kind of paper while you write on it. The pen features accelerometers and what I would assume is a pressure sensor that allows it to tell when, how, and what you are writing. It also records all sounds that are happening while you are writing, and can temporally associate the sounds to the written notes on the paper. This can all then be transfered off of the Pulse onto a (Windows only for now) computer and even published to the web, complete with sound and animated writing. The best thing about the Pulse is that it’s based on the Java ME platform and exposes a (apparently complete) development API, meaning pen-based applications can be designed that make use of all of the pens features. I have not yet had a chance to experiment with the API, but it’s on my schedule for tomorrow, so more details are to follow. Until then, check out these YouTube Videos for some more details.

For anyone interested in developing (or discussing the development of) Pulse applications, I started a Ning-based social network. If you were lucky enough to acquire a Pulse at JavaOne, please join!

JavaOne 2008 – Day 3

Day two’s keynote was from Intel, basically the same as AMD’s evening general session yesterday. Blah, blah, blah, we improved JVM performance, blah, blah, blah.

With that out of the way, it was off to Groovy and Grails: Changing the Landscape of Java Platform, Enterprise Edition Patterns, which was unfortunately a bust. I think I’m grails’d out. The only thing new here was a couple new metaprogramming methods that I probably would have found by myself. Not that it was a bad session, it was just the same as the other Groovy sessions so far.

Next came Mylyn: Code at the Speed of Thought. Very cool. I can see Mylyn being very useful, especially when dealing with junior developers. Mik Kersten, the presenter and the Mylyn creator, also noted that there was a “statisticly significant increase in the productivity of a 100-developer test group.” Sounds promising, but I’ll need to play with it to see if it will fit into my employer’s methodology.

There were other sessions, but the only other one worth mentioning was Developing Semantic Web Applications on the Java Platform, which was a panel moderated by Henry Story, Sun’s Semantic Web Evangelist (I want an evangelist job title!) From this session, I was introduced to Twine, Tabulator, GRDDL, and Mulgara. Definitely worth a little more investigation!

Tonight was JavaOne after dark, the closing party held on Thursday night so that everyone can catch a red-eye home tomorrow night. This year’s bash featured Smash Mouth, and turned out to be pretty entertaining when they played a few Zepplin songs before closing the show. (An amused on-looker said they ran out of their own songs so they started playing something people would know!) I was able to grab some video with my camera, which I’ll post to YouTube when I get home, but sadly there was no encore and we were back in the hotel by 9pm.

JavaOne 2008 – Day 2

The general session this morning was not quite the same as yesterday morning’s, which I suppose is understandable, but it was still pretty informative. Today Oracle showed off its developer tools, which are interesting, but being mainly JSF, not very appealing for my own use.

My favorite session of the day had to be Groovy, the Red Pill: Metaprogramming — How to Blow the Mind of Developers on the Java Platform presented by Scott Davis. This session was incredible. Scott speaks like a televangelist and by the end of the presentation seemed to have half the audience ready to stand, shout AMEN, and follow him as a new religious leader. I now have absolutely no doubt in my mind that Groovy is an amazing and powerful language and that I’m going to try my hardest to make it part of some project I’m doing in the near future.

My second favorite presentation was definately Creating a Compelling User Experience presented by Ben Galbraith. It wasn’t anything groundbreaking or new for me, but it was a very well-done presentation on design for the typical Java engineer. Ben made a variety of good points, including my personal favorite, pay attention to users goals but don’t let them design software.

Third runner-up for favorite goes to How to Implement Your Own OpenSocial Container on the Java Platform by Chris Schalk and Paul Lindner. This session basically covered Apache Shindig, which I did not even know existed. Also mentioned in the presentation were Guice and Enunciate, which I will definitely be investigating further.

Not much shwag today, and I didn’t win anything from any of the drawings (despite wearing my Swing Application Platform shirt), but overall a good day. Although if I can request anything from the JavaOne gods, how about a little variety for lunch, or at least a different kind of pasta salad with the sandwiches!

JavaOne 2008 – Day 1

In case any of you missed my tweet, I learned so much today that it actually took me a good twenty minutes to remember what my first session was about!

I eventually remembered, it was The Duke and the Elephant: PHP Meets Java. Interesting concept, but doesn’t seem ready for prime-time quite yet because it does not support JIT compiling the PHP to bytecode like the other scripting languages like Groovy and JRuby do. If you’re interested, the project is WebSphere sMash and it is being developed by IBM and falls under the umbrella of the ProjectZero incubator. It is being developed transparently, the source code is available, but it is not open source.

Session number two was by far the best of the day, JAX-RS: The Java API for RESTful Web Services. This session covered the basics of REST and then went through an incredible live-coded example using the JSR-311 reference implementation Jersey. I love the simplicity of the annotations and the fact that Jersey can run as a Java SE app without a web container opens the door for some interesting implementations.

The next two sessions really weren’t that interesting, but after dinner I went back to the Moscone Center for Jersey - RESTful WebServices Made Easy. This session was not as technical as the JAX-RS session, but still provided some neat demos (including an example using a SunSpot), and offered some insight into the Jersey project. Because I enjoyed the REST sessions so much I’ll be checking out the blog’s of the presenters: Marc Hadley, Paul Sandoz, and Jakub Podlesak.

So far, other than the food, I’m very impressed with JavaOne, and I might even go as far as saying it is better than TheServerSide Symposium was last year. Although the Cult-of-Java is almost as extreme as the Cult-of-Apple, which I do find pretty odd. The keynote was entertaining and interesting, but not that interesting!

Grow Up and Code

Groovy, like Ruby, is one of those DRY, elegant, and fun programming languages. In fact, one of the Groovy mantras is “the things you do the most often, Groovy makes the easiest.” That’s a pretty powerful statement, but with all things powerful, with great power comes great responsibility.

Groovy does some things that are inconsistent, for instance, consider running the following block of Groovy code:

def list = [1,2,3,4]
println list.class
dev map = [key1:"value1",key2:"value2"]
println map.class

Line 2 returns the class name of the list variable, in this case java.util.ArrayList; line 5 throws an error. This inconsistency is because Groovy allows the fields of a map to be accessed like a property, which means map.class is equivalent to map["class"] which refers to a key class in our map which does not exist. Because Groovy is interpreted and not compiled there’s no compiler to catch this error and it is possible that without an adequate amount of testing or review a piece of code like this could make it out as a bug. This point was brought up as a problem with Groovy to Jeff Brown, the instructor of the “Rapid Web Development with Groovy & Grails” Java University session at JavaOne. Jeff agreed that it was an issue, but basically just ignored it and moved on. I argue that it’s not a problem with the language it’s a problem with the developer.

Groovy’s documentation contains a list of things you can do with Groovy but probably shouldn’t, on said list, this problem is identified as number one. Groovy provides the ability to write unit tests, which if done correctly should catch this bug. But more importantly, a programmer should know the language he’s programming with, or his code should be reviewed by somebody who does. If your methodology allows for a bug like this to be released into the wild, you have bigger problems.

Groovy is a programming language for people who know how to program. People who realize the simplistic beauty of the syntax and the elegance it provides for solving problems in a DRY manner. Groovy is not for beginners, beginners need time to learn how to code before they should be allowed to take shortcuts. More importantly, beginners rely too heavily on tools, tools that more often than not act more as a crutch than an asset, and tools that cannot catch problems like the one above.

My solution? Grow up and code. When you’ve written enough code to realize that the best IDE is Vim, Emacs, or TextMate, and a terminal, you’re ready for Groovy and Grails. When the necessity of unit testing finally clicks in your head, you’re ready for Groovy and Grails. When you finally understand that code is poetry, you’re ready for Groovy and Grails. Until that point, keep writing code or find a new career. I can only hope that maybe one day you’ll understand, but if you never do, keep your opinions in your own space and don’t pollute our elegance with your misunderstanding. Just because you can’t write beautiful code doesn’t mean the rest of the world can’t.

Welcome Bokardo Readers!

If you’re here because of Josh Porter’s posts on social network and social niche sites on his blog Bokardo, you might find these posts interesting:

If you like what you’re reading, please subscribe! I post every weekday on “Web 2.0” topics like JavaScript, CSS, web semantics, and of course the social web.

(Please excuse the looks, I’m not quite done with the theme for this site yet, but it looks much better than a week ago!)

Duck Punching JavaScript - Metaprogramming with Prototype

First, let me explain the title for those of you who live in Java world. The term Duck Punch comes from Ruby programmers and refers to the concept of duck typing used by Ruby and other languages; if it walks like a duck and quacks like a duck, I would call it a duck. With that being said, duck punching is summed up nicely by Patrick Ewing with the following:

Well, I was just totally sold by Adam, the idea being that if it walks like a duck and talks like a duck, it’s a duck, right? So if this duck is not giving you the noise that you want, you’ve got to just punch that duck until it returns what you expect.

It is slightly violent, but makes for a good article title. Now, getting to the point, metaprogramming is writing programs that write or manipulate programs, including themselves, at runtime. This type of programming can be accomplished in many languages but is currently a pretty hot topic in languages such as Ruby and Groovy. Java has a similar concept known as Aspect Oriented Programming (AOP), which introduces pointcuts to a program that can then be modified at runtime via bytecode manipulation or dynamic method proxies.

My example library/method below allows a Prototype-enabled class to have every one of its methods wrapped with a before and/or after method to introduce additional functionality at runtime. This concept is demonstrated by this example, note that the modification occurs on the class level and any existing or future instances of that class are affected. Thanks to Prototype JS, this code is pretty simple:

var Aspect = Class.create();
Aspect.prototype = {
	initialize: function( clazz, before, after ) {
		var members = Object.keys( clazz.prototype );
			function( name ) {
				if( Object.isFunction( clazz.prototype[name] ) ) {
					var oldName = "old_" + name;
					clazz.prototype[oldName] = clazz.prototype[name];
					clazz.prototype[name] = function() {
						if ( before ) before( name );
						var me = this;
						var args = $A( arguments );
							function( arg ) {
								me[oldName] = me[oldName].curry( arg );
						if( after ) after( name );

This code relies on one of the core concepts of JavaScript OOP; a JavaScript object is nothing more than an associative array. Knowing this, when passed a class, we can get a list of all class member names using the Prototype Object.keys method as shown on line 4. Once we have the member names, we loop through all members (line 5) of the class. For each member we check if it is a function (line 7). If it is, we alias the function (line 9) and create a new function (line 10) in its place that wraps the aliased function with calls to the before (line 11) and after (line 20) functions we pass in. Notice the use of clazz.prototype starting on line 9, the prototype keyword is necessary to modify the class. If you rewrote this method slightly and didn’t specify the prototype keyword you could modify an individual instance of the class instead of all running instances. Also notice the curry method on line 16, currying is a metaprogramming technique (provided as a helper by Prototype JS) where a function is modified with each call so that the arguments passed into it become part of the function and are no longer necessary. This allows us to pass an arbitrary number of arguments into the aliased method. (Remember, in JavaScript, arguments do not need to be defined for a function and can be accessed via the arguments array.)

The above code can be called on any class in the document by running the following code, assuming before and after are pre-existing functions and SampleClass is the desired class:

new Aspect( SampleClass, before, after );

You can see a complete (although pretty useless) example of this method here, or view the source code for the test or the sample class.

So, where is this useful? Since we’re simulating AOP, we can use this for any cross-cutting concern, a perfect example being logging or profiling. Watch for a future article where I use this technique to automatically implement JavaScript profiling similar to what I did in my article on the dollar function using this technique. One final note for the Prototype geniuses out there, Prototype does provide a wrap method that provides this functionality, but if you used that you never would have learned all the neat things about JavaScript in this example!

Reboot Complete

For those of you visiting to check out my changes for the May 1st Reboot, I’d like to welcome you and encourage you to subscribe to my RSS feed. Sadly, I did not get my design totally finished thanks in part to life in general. If you’ve seen my design before the reboot I think this is a definite improvement; however there are plenty of tiny details that still need a lot of work.

Since I’m away for most of next week at the JavaOne conference in San Francisco I’m planning to do a bit of work on this site while in the air. So, with any luck it should be prettier than it currently is sometime next weekend. If you have any comments, concerns, or suggestions, please feel free to leave a comment on this post. This is a design in progress and I welcome any and all criticism.

Regular updates should now resume since I don’t need the reboot splash screen any longer, so check back tomorrow for a brand new article.