September 8, 2010

Posts Comments

You are here: Home / Rants

Do people at Microsoft actually use SourceSafe?

May 18, 2007 By Bruce Kroeze 4 Comments

Working for one of my clients this afternoon, I had to figure out a reasonable way to work with Visual SourceSafe. I program on a Mac, and my only access to Windows is via a Parallels installation of Windows Vista.

That’s not really the problem, Parallels is a stunningly good piece of software, and I think Vista is the least annoying of the Microsoft Operating Systems. So I can access VSS fairly easily. The problem is what an incredible hunk of junk that software is.

So really, if any Windows programmers read this, could you tell me if people at Microsoft are honestly forced to use that software? Why? Have you ever used good source control software? BitKeeper? SVN? GIT? What is it that is good about VSS? Is it just the trivial integration with Microsoft’s dev tools?

Look, I hate operating system wars. I just don’t care anymore, they aren’t worth fighting for me. But I simply don’t understand how VSS is still in the world and still used by anyone. Not when even ancient, cruddy old CVS is better, faster, and easier to use. VSS has absolutely no advantages I can see.

It makes me happy that this particular job was bid as an hourly gig. VSS overhead is adding significantly to the time I’m using and thus charging. Fine by me. If you are going to insist I use a moron tool, then you’ll need to pay for the time wasted.

[tags]vss,sourcesafe,version control[/tags]

Filed Under: Rants

The code won't be ready…

April 20, 2006 By Bruce Kroeze 3 Comments

Bullheaded I was in an emergency meeting recently where the company had sold a big project, based in large part on a super-duper-solves-everything process tool. This tool, this magical tool, is to be the company’s leverage for bringing in all the facets of the project on time and under budget.

Problem is, there’s no such tool. They need to write it. Ouch. There’s a project plan and a timeline. The timeline says the project will be done in June. The work on the project that the tool is supposed to facilitate needs to start now.

What do you think the brilliant idea was to solve this problem? “Can you write us something to help us do this?” No! I can’t. I mean, I could, but what you need is the mystical-magical tool you’ve spec’d. In the meantime, what you are going to need to do is to work out a clear chain of responsibility, and actually talk to each other. You’ll need to manually do the things the tool is supposed to make simple.

The great thing was, I actually told them that. Maybe it is because I’ve been laid-off that I could actually point out the foolishness of what they were asking. You need to talk to each other. You need to have a defined flow for the various stages in releasing the client’s content. I can help you by setting up a document repository using our CMS. But that’s it.

It was such a liberating moment to tell them that they are going to have to live in the hole they just dug themselves. Me, I’ll be at my next employer. The tool will never happen, and that’s why the company just had to do a mass layoff. Plenty of vision, no execution.

Filed Under: Rants

XML Is Java's Scripting Language

March 13, 2006 By Bruce Kroeze

Troll Great article at Lesscode.org, responding to Gosling’s dismissal of scripting languages.

Usually, I ignore attacks like Gosling’s as not worth my limited time and attention. I love Python, and it really doesn’t bother me when the ignorant attack my language-of-choice. This article is better than the original by orders of magnitude, due to its heavy linking and its excellent reader commentary.

My favorite quote from the article is: "this is why XML is used so heavily in Java for things like O/R mapping, dependency injection, configuration, build processes, etc. — XML is Java’s scripting language". It is actually from a reader comment, which is worth quoting in full.

But Ruby, Python, Perl, Smalltalk, etc. are not specialized scripting languages. They are general purpose programming languages. I believe one of the reasons the term “scripting language” has stuck with them is partially because it’s become so common to create mini-languages (i.e. DSLs) in dynamic languages that are specialized for certain tasks. So it’s sometimes hard to separate the specialized pieces from the general purpose pieces. Contrast that with static languages, where you are forced to create a completely separate “scripting language” when you need to provide a constrained/specialized language (this is why XML is used so heavily in Java for things like O/R mapping, dependency injection, configuration, build processes, etc. — XML is Java’s scripting language). In dynamic languages, you are generally not required to leave the core language to get that specialization: you use techniques like meta-programming and DSLs or just include/require/use some designated file at a designated point and let it do it’s thing with the API.

Filed Under: Java, Python, Rants

What is it about PHP

February 22, 2006 By Bruce Kroeze

PHP is a weed I’m no fan of PHP, I believe it is a terrible language which produces insecure, ugly code almost all the time, yet I use it. It powers this blog, for example, and it will be powering the online store I am about to launch. Why do I use it when there are so much better languages and frameworks available?

Ian Bicking discusses this at length, focusing on the features he’d like to see in a serious competitor to PHP. He’s got some great points and a long laundry list of things he’d like to see, but his article doesn’t answer my basic question. Why do I use a language I personally think is extraordinarily poor?

Installation & Availability

That’s it, right there. Installation is king. Installing a PHP app is usually as simple as dropping the files in place and setting up the database. Bam, done. PHP is PHP, it usually “just works”. There is no careful setting up of fast CGI, or debating about Apache vs. Lighthttpd. There are no awkward CGI interfaces to tweak for your particular installation. Just drop and go. That is half the battle right there. And, I believe, it is a lot of the force that drives the second half of the winning equation, availability of “good enough” applications.

Availability. Name a better, more configurable, more active blogging framework than WordPress written in a good language (note, this does not include Perl). Ah, there are some, but they need work, they need to be finished, or “just need this part implemented”. I don’t have time or the interest. I run a couple businesses, and have a full time job. I have a lot of programming projects to do, and writing a new blogging engine isn’t one that interests or will pay me. So, WordPress/PHP wins.

Kinda sad, really, but it least it isn’t .net. PHP is bad & ugly, not evil.

[tags]PHP,rants,wordpress[/tags]

Filed Under: Rants, Wordpress

Bitter Java

February 13, 2006 By Bruce Kroeze 3 Comments

Cup of bitter coffee I’ve been saying for years “The only time I program in Java is when someone pays me.” I was half joking, just stupid office banter, but I’m getting more and more sure about that opinion. Rant mode – engage.

I spent the entire day today chasing down Java configuration errors when upgrading Resin 2 to Resin 3. It is a moderately complex application I’m upgrading. Built on Java 1.4, Spring, Hibernate, and JSTL, it really shouldn’t be that hard to upgrade. After hours of careful debugging, I found that it is a bad combination of JSTL and newly strict adherence to the JSTL spec that is causing most of my upgrade woes.

Basically, Resin will no longer allow me to access a public static method of a class using Javabeans syntax conventions. Why? Because it is static. Not because it isn’t useful, but for the sake of strict interpretation of “the rules”. I seriously hate that attitude, which is very prevalent in the Java world. So, I need to rewrite many of my classes to make non-static class methods to access the same information I used to be able to get at directly. It leaves a bitter taste in my mouth.

Don’t trust the programmer

But that sort of “don’t trust the programmer” attitude is depressingly common in Java. Most everything is “strictly typed”, sure, but to work with a collection you always have to cast the object back to the proper type. Isn’t that “secret scary knowledge the programmer shouldn’t have to know”? I submit that it is. Doesn’t that break the supposedly big advantage of finding errors at compile time? Yes, it does. Can a good programmer get every bit of the same advantage and early error-validation by doing proper unit checks? Of course he can. So why do it like that, why be so wordy and needlessly strict? Because that’s Java’s corporate, designed by committee, not for love, spirit.

XML Sit-ups

There are a lot of people debating the merits of the so-called “XML sit-ups” that many frameworks require. Java invented the XML sit-up. Spring is a gorgeous framework. It almost rescues Java in my eyes, but looking at the horrible horrible config files it requires almost brings junior programmers to tears. Seriously, take a look at the Spring Acegi security framework configuration files. I think that may be one of the most complex, interleaved, multi-layered config files I’ve ever seen. I strongly believe that that particular XML serves absolutely no purpose, and would actually be clearer, cleaner, and more testable if it was instead expressed in code.

It saddens me to see Zope 3 heading down that same XML path. It is a myth that anyone other than a programmer will ever really be editing the config files. Why add needless cruft, delays and obfuscation? I don’t buy the “then it can be validated using XML validators” argument for one second. That’s like smashing an ant with a hammer.

Ugly Ugly JSTL

JSTL is another bitter pill. It is just unforgivably wordy. It is so amazingly wordy, and yet it fails to even remain valid XML. What the hell? I can forgive Zope Page Templates which are very wordy and involved, yet manage to remain valid XML the whole time. I still don’t really like them, but at least I can understand why some people do. JSP/JSTL on the other hand is so crufty, so layered and whacky, so inelegant, that it feels like the wrong solution every time. The programming community should simply throw it out and take a look at a decent, mature, truly object oriented solution like Cheetah for a well designed, terse and effective templating system. Why continue adding to the ugly pain that is JSP/JSTL? I have to think it is simple NIH syndrome at this point.

Conclusion, anyone having fun?

What I honestly find myself wondering is whether anyone actually programs in Java for fun. Or do they all do as I do, program in Java on the day job, come home, strip off the straightjacket, and dive into Python, Ruby or PHP? I hope so, for their sake. Java is a language with a broken spirit, and without exposure to other languages, I fear that Java developers will have their spirits crippled as surely as if they were VB developers.
[tags]Java,Spring,Hibernate,JSTL,Zope,ZPT,Acegi[/tags]

Filed Under: Java, Rants

Logging is good for frameworks too

January 19, 2006 By Bruce Kroeze

Log sculptureOne thing I just don’t understand is why more people, especially framework designers, omit or skip logging. Django appears to, which is incredibly annoying to me. It is a complex framework, which makes all kinds of assumptions and relies on convention to infer a lot of functionality. That’s great, but being able to “turn up” the log-level and see some discussion about what decisions it is making, based on what criteria it is using would be incredibly valuable to me. Not only to me, I wager, but to everyone who is learning the framework, or who is teasing out a difficult bug. Yet going in and adding framework-level logging is almost impossible, even on an open-source project, since your changes will not be accepted and will quickly become a merge nightmare.

Don’t believe me about changes “not being accepted”? Here’s proof. (That’s not my bug, by the way, just proof). The developers closed the ticket saying they “fail to see what this gains Django”. Foolish and shortsighted.

Logging is preferred by most senior programmers over line-by-line code stepping. It is both more efficient, and allows for post-mortem analysis of problems in a way that debuggers never will. Yet many act as if it is a nice-to-have, or worse an irrelevant distraction.

Shortsightedness is deadly

I once worked on a team with a programmer who refused to add any logging to a super-awesome-framework he’d written for Java. Evidently the framework was the solution to everything we needed. I challenged him in a team-meeting about his refusal, talking about the numerous benefits of good logging throughout a system. He replied “I don’t write bugs, so I don’t need to waste time logging to find them”. I had him fired, and good riddance, within a week. Attitudes like that have no place on a software team. It was his foolish assertion that he didn’t write bugs that was the final nail, but his refusal to see the benefits of logging certainly didn’t help his case any.

Logging is built-in to Python, and is a commonly available module for Java. It is high time to make this practice part of generally accepted programming standards for frameworks. Don’t want a log? Turn it off. But you should always be able to get one. Always.
[tags]logging,java,python,django,rants[/tags]

Filed Under: Best Practices, Django, Python, Rants