tmikew

How does one know a great book with out consuming some junk? We learn when we do it wrong up much more often than when do it right. It is not always clear in the beginning that putting business logic in with the view or the data layer code will later be impossibly difficult to untangle. I would suggest read what you want then do what you think is best. It doesn't matter if it is completely correct. (whatever correct is) Some good peer review will keep the bad trouble away, or at least the decision to keep it will be made with the eyes open. Nothing will create a great programmer faster than untangling those darn tangles.

I agree that the effort is large, and the browser platforms are constantly in motion. I was mostly just musing about it. My gut feeling is that getting Java script up to speed on the server side is just as much if not more work. Look at how much work has gone into the tools just for Java for example. Years. Before I get flamed, I will say that I am not bothered at all that some folks are willing to take up the effort to do it anyway. That is how things get done. I am just wondering about it.

This is kind of cool, but who is going to digest all of it? The techno folks may have some technology pieces working, but nobody out in the main world would be able to figure it out. I got a little dizzy just looking at all the links to all the pieces in just this one article. Let alone actually reading them all.

I like Java script but I think making it go server side is backwards. Why not make Python or Perl or Ruby go client side instead? (I am sure plenty of folks smarter than me have already thought about and probably worked on it.) Those languages already have all the parts they need except a connection to the browser dom. Java script has a connection to the dom and practically nothing else. These other languages have been getting tweaked for years on the server side. It just seems like such a big byte to get Java script to work as a regular language like the others. It also ignores some of the things that are lurking like Erlang and Clojure. It sounds correct that there are lots of Java script programmers. However are there lots of Java script only programmers? I doubt it. While it is compelling to write one language every where, I dream about it sometimes, we aren't close yet.

So embedding the Perl, or whatever, interpreter into the browser is probably a chore, but it is also probably doable, the browser should be able to deal with multiple languages. I think it is just that the people that are capable of doing that job looked at it and said. "Crap! I will just learn Java script." So the reality in my mind is that programming in two or three or four languages is just easier than doing all that other work. Everybody does it. In fact we say I know Java, or Python, or Java script, but that is just a word to give us a frame of reference when we communicate with each other. In fact what we really know is how to program computers and Python is a subset of the total global programming skill that I have. It is a like speaking English in some specific domain. There is jargon everywhere, one can speak English but one tends to get easily lost if one listens to lawyers speak to each other or doctors, and one is also not a doctor or a lawyer. Does that mean we should create a generalized English that both doctors and lawyers can use in each of their specific domains? Seems a little silly when one thinks about it. Is making Java script work everywhere is really buying all that much?

I am you. I'm in my early 40s. I worked for BigCorp 11 years in my position. I had a long commute. I made lots of money. I have a house and 3 small children. I wasn't seeing enough of my kids. BigCorp is outsourcing to India. I wasn't in jeopardy of loosing my particular job, but I wasn't allowed to program. I had to get the work done through the development teams in India. My immediate boss was ok, the guy a couple up from me I considered completely incompetent. I hated my job. I can't tell you how bad.

6 weeks ago I walked into the bosses office and resigned. He tried all manner of stuff to get me to stay. I wouldn't do it. Previous to me walking in there I had been thinking about in my own head. "If they would pay me BIG $$ would I stay on for this latest disaster project, and get my bonus for this year?" The answer was NOPE. So by the time I walked in there the ship was already sunk and my boss couldn't save it. I had no job to go to. Interestingly my boss gave up after a few minutes and told me good luck, and he felt his job sucked to and shook my hand. My co workers also congratulated me and I left on good terms.

6 weeks later. I have some savings, my house is nearly paid for and my payment is small anyway. I can make it for a while without doing anything different to our monthly budget. I will need to figure out health insurance soon. That is the biggest thing on my plate. Something else happened. I slowly realized that the pain at work had crept up on me a little at time for about 2 or 3 years. I was like the frog in the slowly heated pot, I was dying there. I feel 100% better now. I can't even tell you how much. I have all sorts of ideas that I might try and do. In the spring I will find some sort of job just to buy the groceries. You couldn't drag me back to where I was with a team of horses and I was making north of 100k base, plus bonuses, and nobody was really telling me what to do. Yet still it was not worth it.

The time with ones kids and family are worth way more than the money. Being able to sit and decide what I might do is exciting. I mean I feel the best I have felt in some years, and I am unemployed with no prospects. I am a happy man.

Don't do anything crazy just because of me, but I am you 6 weeks later...

I would have to agree with thinking as well. When I first started programming I would just brute force my through whatever problem. After some years I realized that the 3rd or 4th iteration of something was commonly the best solution and the rest were crap. Then I realized I could skip the coding for iterations 2 and 3 and just think about the problem a little harder, and go do some reading about it. Thinking works and it saves me a lot of time and frustration. Learn an editor Emacs or Vim. I like Vim. Learn a scripting language Perl or Python. I like them both, for me Python gets the edge.

I would just say this for folks who don't like unit tests because it takes longer. Push yourself away from the keyboard and think about it. When one writes codes one writes unit tests in ones head or the code doesn't work. I submit that we always write unit tests. The difference is in one case we keep it so we can run it over and over, in the other case we do it anyway in our heads then throw it away. I am not convinced that writing unit tests now takes any longer. We all know it saves our bacon later.

I have personally thrown out entire chunks of code except the unit tests and started from scratch to get things working again. I don't think the value of this can be understated.

I would agree, and add to this comment. If I can't figure out what the sensible name is then what exactly is it that I am writing? I have found that writing the wrong name even for a local private variable will often get me at least a little confused about what I am doing because it doesn't read correctly.

I used to think in terms of methods and data structures, say about 5 years ago. I was thinking bottom up. I learned (slowly) that I could not sufficiently communicate to the business folks what was happening. Their eyes would just glaze over. They also rejected 90% of my work by the time they got to see it. We were simply out of phase with our communication.

Today I have learned to think in work flows and the visualizations of the UI. This is how the users of the program view it. To users the UI is the program. Now the users accept my work 90% of the time. I seldom think about the methods or data structures anymore until I am actually sitting there typing it in.

When I first read the question I almost fell off my chair. The answer is YES. I have used source safe, star team (briefly), cvs, svn and now mercurial. I haven't used Git but I understand that it is conceptually similar to mercurial. I keep most everything in mercurial repositories, not just my projects.

I much prefer the distributed stuff. Just make a repository anywhere now it is an awesome concept. Soooo much easier than fiddling with an svn server for example. (I am talking about the set up of the server.)

I personally think it is completely worth it to get your head wrapped around the idea of distributed revision control. Aka mercurial or git.

Rolling eyes and shaking head at all of the other folks on this post who recommended avoiding learning revision control as soon as possible. That would be a mistake.

Do some research on a fellow by the name of Napolean Hill you may find it interesting.

You will not likely have a better opportunity than now to do this. It sounds fun to me and I am an old guy. I keep wondering. Why would you not also earn a little money along the way as needed? Doing whatever.

Missing the point. Every "Hell yeah" project does not turn out to be easy or even fun. In fact I agree that finishing any project is usually tough, some aspect of it sucks. Why are so many things left unfinished? Doesn't matter what the project is pick one. Where I work there is unlimited demand for time and features and projects compared to finite time available to work on them. The most successful folks have learned the skill of figuring out what to say no too. In the face of unlimited demand, one might as well only choose the "Hell yeah" stuff. Life is better that way. It took me a long time to figure that out. If all of the stuff one said "Hell yeah" to was easy life would be boring. Running a 100 miles doesn't sound to easy to me. If one does survive the hard phase on a "Hell yeah" project that is what the best things life are made of. Might as well try out as many "Hell yeah" things as possible. I am pretty sure my wife wasn't saying "Hell yeah" when my 3 children were being born. But I could have missed something...

Why do you think you are not sharp? I bet your problem is that all of your problems in your current business domain are solved and you are bored, not dull. What is a little dull is reading through lists of academic achievements and future academic proposals or thoughts. It comes across a little like trolling for compliments.

I am 44 I have house, wife, 3 kids. When I was 23 I was freaking clueless, though I didn't think so at the time. (There is a good chance I still am clueless) School was easy, Navy was easy, studying and taking tests and getting good scores was easy. I was bored and figured there wasn't much else to be done. I was completely wrong about that.

So coming from an old guy. I would suggest dumping your easy job and finding one that is challenging for you. There are plenty of hard problems to solve. All of the sharpest people I know never let go of a hard problem until they figure it out, and they refuse to slog through the easy stuff like some kind of drone. There are surprisingly few people in this category. All of the sharpest people I know read continuously about a wide variety of things, and they build or write about things based on their reading. All of the sharpest people I know put down the keyboard and have some other really interesting thing they do.

I agree. In other words correlation is not causation.

I agree it is tough. Coming from java land it always seems like one is either mixing java in the html or html in java. I have also never been totally convinced about the separate people argument. Not that it won't work, but that company's that I am familiar with don't hire both people very often the developers build both the UI and the business logic, which of course further complicates the issue, because the developers are always taking shortcuts. Everything I have ever worked on is mixed up to some extent, and it works, and we manage to maintain it. Still the arguments in the paper are compelling.

It is possible to use ajax and Javascript without getting things to mixed up, but again the discipline by the developers I am involved with is sadly lacking. There is another article I will try and find to post. Humble Dialog that fits with this paradigm.

For me when I first encountered this particular post on REST a couple of years ago it was like an ah ha moment. SOAP is just one complex layer. Struts is another, actually a container in a container. Having messed around in J2ee land for while this article made me realize that most folks didn't know or didn't care what a stock J2ee container could do if one started thinking RESTfully.

Then we built a whole enterprise web application using just a stock J2ee container and RESTful style thinking. How much simpler! No extra frameworks to learn. The UI became completely decoupled from the services. The services are completely decoupled from the J2ee container, naturally. All the container does is resolve the nouns to a service name and give a call back to the appropriate verb method, doGet, doPut, doDelete.

In fairness we are not 100% RESTful there is some legacy stuff that relies on the session. However having done a few SOAP/WSDL services and tons of Struts actions or Spring "injections" I must say that REST is in my opinion a much cleaner way to code for web apps. Whenever I hear about some implementation needing a SOAP/WSDL service I run the other way as fast as possible. I won't even debate folks about it anymore, I just refuse to work on all that complexity.

As an aside I have seen here and there some frameworks the purport to use REST. I don't really get this. Why would somebody need and additional framework to make something RESTful? I have done it with J2ee and just plain Apache. I believe the web itself to be the framework, I could be way off in my thinking though, it wouldn't be the first time. Anybody have any clues about what a RESTful framework is for?

Completely agree. I once had somebody ask me during an interview to write a binary search on the white board. Very tough in that circumstance for me, completely blew it. Interestingly that was 11 years ago, I am now the chief architect and the other fellow has been gone for years. I doubt I could today just stand up and write a binary search from scratch that was worth darn. Even though it is not that tough of a problem.

Programming in my opinion is a reading comprehension skill, solving cute little technical problems won't build large scale maintainable solutions. Even though they are fun to throw around at interviews they don't prove much. :)

I prefer JSON. Though I do agree with the other comments that xml is more readable if the structure is big, and that one can easily (and perhaps should) do both.

In practice I have noticed that where I work we tend to have complex data structures but not very deeply nested ones. We wrote a simple find function that recursively traverses the JSON structure looking for keys. Not anything nearly as powerful as XPath but sufficient.

It tends to be highly useful in my experience to create a list of objects. For example instead of a list of phone numbers a list of phone number objects. One may then easily add attributes to the phone number. Primary, cell phone, home phone etc. This tends to be highly flexible in that attributes may be later added that were not at all considered up front.

Of course all of this can be done with xml as well. JSON just seems more convenient. If I add an attribute in Javascript or Python I can just use it and get on with it. No messing with my SaxParser or building up some new XPath. Again I am not bashing xml at all, this is just my take.

In practice we use JSON exclusively in the core services for input and output. When we need to use xml we convert it to JSON and then back to XML as a filtering process rather than fool around with our core services. This adds overhead but keeps us flexible and loosely coupled.