Java is mainly used in Web applications that are mostly fairly trivial. If all we do is train students to be able to do simple Web programming in Java, they won't get jobs, since those are the jobs that can be easily outsourced. What we need are software engineers who understand how to build complex systems.

Although Dewar was speaking in terms of Java, the statement applies to the broader world of web apps (and many desktop apps) in general.

That property is precisely what allowed frameworks like Rails and Django to come into existence and get popular. Soon enough, the money will dry up for implementation because it's too easy to generate solutions for most problems you'll encounter - either using a framework, or a content management system like Sharepoint or Joomla, or even by hiring someone to generate it for you. Yesterday I recommended a potential client just go the CMS route.

Nowadays, most of the skill involved in writing web applications amounts to gluing the disparate pieces together. How long until someone figures out how to commoditize that? Instead of knowing only how to implement solutions to problems, you need to be skilled at problem solving itself.

Right now, you might be in a position where you can kick back and count your money while you smoke a cigar.



But if you're in the business of building web applications and you're not innovating new kinds of them, you're doomed. You can chase vertical after vertical and keep building the same apps for quite a while, but if you don't get into generating them, you're on the way out as people come in who can do it cheaper than you and with higher quality.

Generation is to web apps as prefabricated steel buildings are to construction. Except almost no one cares if their web application was generated or not - they just want the lower price.

I suspect that even if you are generating applications, at some point in the future, the number applications needing to be generated will not have grown as quickly as the number of people who can generate them.

People are building complex data warehouses and doing analysis and reporting on them with GUIs and Wizards right now. You still need the knowledge pertaining to data warehouses, but that knowledge is becoming easier to obtain for more people with less effort than ever before. That trend, which fits in with the general trend of information democratization, is unlikely to reverse itself.

If you don't plan for change now, you'll end up shocked.



And then how long until you're pulling out the cloth-eared elephant?



What Dewar said is true: Web applications are mostly fairly trivial. To survive, you need to learn the fundamentals so you are applicable in various kinds of programming and for different platforms. If you really want to be safe, you need to be innovating, not building copy-cat applications with a twist (and especially not from scratch?!?!).

Giles Bowkett put it well when he described the effects of incompetent programmers' entry into a particular market:

Every programmer should also read Chad Fowler's "My Job Went To India" book, where he explains that as larger and larger numbers of programmers adopt a particular skill, that skill becomes more and more a commodity. Rails development becoming a commodity is really not in the economic interest of any Rails developer. This is especially the case because programming skill is very difficult to measure, which - according to the same economics which govern lemons and used-car markets - means that the average price of programmers in any given market is more a reflection of the worst programmers in that market than the best. An influx of programmers drives your rates down, and an influx of incompetent programmers drives your rates way the fuck down. (Bold emphasis mine)

The problem, in my view, is that the influx of incompetent programmers is inevitable.

So building well-known applications with twists becomes much like the would-be artist who looks at Pablo Picasso's work and says, "I could do that."

The obvious exception is that applications are not (usually) like art. Well-made knockoffs of the original aren't likely to be differentiable by customers from the cheap knockoffs, so the masses of incompetents and maybe the original end up defining the market in the long term.

After you've seen it, you could do this:



To which we all respond, "But you didn't, did you?"

As always, I welcome your thoughts in the comments below.

There are plenty of potential solutions out there, but none of them worked for me. I would get the scrolling working, and then the draggable would move away from the cursor. I'd get it in sync with the mouse cursor and the scrolling would get crazy again. I'd fix that and then no matter where I dropped it, if the div had been scrolled, dropping would fail.

Here's how I fixed the problem:

1. In the Draggable#updateDrag function (~ line 356), on the first line, I changed the value of the pointer argument to take into account how much the container had scrolled:
   
   pointer = new Array(pointer[0] + this.options.scroll.scrollLeft, pointer[1] + this.options.scroll.scrollTop);
   
   At least one of the solutions I recall seeing mentioned this.
   
   
2. In the same function, I changed the first two elements in the p array before the last two elements get pushed onto it:
   
   p = new Array(p[0] + this.options.scroll.scrollLeft, p[1] + this.options.scroll.scrollTop);
   
   This also just takes into account how far the container has been scrolled.
   
   
3. To ensure my droppables were able to receive the draggables given the adjusted coordinates, we need to adjust the scroll position just as we did above. First, I adjusted the code in my webpage that produces the droppables and added a scroll parameter that should be the name of the element that scrolls (the same parameter the draggable accepts):
   
   Droppables.add('slot_1_7_2', { scroll: 'weeklycalendar' });
   
   Since Droppable elements don't generally take a scroll option, we'll need to modify that code in Scriptaculous's dragdrop.js file as well. In the Droppable#fire function (~ line 109) add the folling lines under Position.prepare();:
   
   var point = [Event.pointerX(event), Event.pointerY(event)];
if(this.last_active.scroll){
  point[0] += $(this.last_active.scroll).scrollLeft;
  point[1] += $(this.last_active.scroll).scrollTop;
}

   Finally, just underneath that where it calls this.isAffected, change the first parameter from [Event.pointerX(event), Event.pointerY(event)] to use the variable we created above, pointer.

That should be it. If you've tried the above and still get problems, feel free to leave a comment below, or contact me and I'll do my best to help out.

I haven't submitted a patch because I didn't check to see that this was a general solution. It seems like it should be, but without testing it outside my intended usage, I don't think it'd be accepted anyway. Quite frankly, I'm not thrilled about adding a new option to droppables, but it seemed like the simplest route to fix my problem at the time.

Yes, I tried setting includeScrollOffsets to true and using Position#withinIncludingScrolloffsets in Prototype, and that failed for me too.