DRUPAL MADNESS

Okay, okay. I get it. Drupal was created prior to object orientation in PHP. Sure, that’s fine. Whatever.

And yes, everybody criticizes Drupal for not using OO. Fine, I’m not saying anything new. However, I read through Drupal Programming From an Object Oriented Perspective and I’m still not sold.

Warning: All of you OO acolytes are getting no love from me either. I’m a functional programmer by philosophy, so I think you are all wrong. However, I will say that there are some nifty things that OO gives you, and sometimes its the right solution to the problem you’re facing.

In a previous post, I commented that I didn’t fully understand why Drupal’s documentation, especially from the “community” of Drupal devs, is so piss poor. Well, now I have an answer. The average Drupal dev is about as technically sophisticated as a Baby Boomer who has just recently heard of a Walkman. What I’m saying is, technical skill – in development, programming, shit- even computer science- is seriously lacking in this group of people.

It makes for an interesting conundrum. A kludgey API promotes kludgey solutions. Allowing people to implement round peg in square hole problems makes for a complete mess. Sure, it may act like you want it to act, or do what you want- but its not the right solution. It would be different if the API was pushing an envelop, or breaking down barriers, or even making strides in the way we program and think about application development. But it really just doesn’t do any of those things.

The fact of the matter is, a user can seriously screw up the way the back end of the system performs. And in my book that should Never, ever, ever happen. Users, front end devs, designers- they all are great professional type folks, but they have no business effecting a data schema or building queries (yes, I’m looking at you CCK and Views builder…). And some of the devs I’ve encountered haven’t the slightest clue what they are actually doing to the system when they engage in adding any of these functional pieces to a site.

Drupal is the Karaoke of Web Development frameworks. It appeals to the Lowest Common Denominator- people who want to sing the song but can’t perform at the top level. And while that works for a majority of folks (let’s face it, the Lowest Common Denominator is pretty big, for the most part), ask a Karaoke singer to perform Nessum Dorma and you’re not going to get what you bargained for. I say keep Drupal in the medium it belongs, because stretching it too far may just create a big mess.

The weirdness that is Drupal…

I’m someone who prides themselves on being open minded.
So after some time of not working exclusively with Drupal, I’ve jumped back into it full swing.

I will preface this whole post with the following, mantra-like, thought: Drupal 7 isn’t as bad as Drupal 6.

But let me tell you- the Drupal source code is the most hideous, ugly, kludgy thing I’ve ever worked with. Here’s the thing- Drupal tries to excuse its ugliness by hiding behind the argument that PHP wasn’t object oriented when they created it- but that doesn’t mean you shouldn’t put significant effort forward to make it object oriented now!.

I’m not going to sit here and defend Object Orientation as a philosophy or as a standard of practice. I’m just saying, if the language you’re coding it at least tries to reach for object orientation, then you should put forth the effort to do so as well.

I quote:

Although Drupal does not make thorough use of the native OOP features of PHP, the Drupal code base and API does reflect some principles found in object-oriented programming and design.

Really? So you’re saying that its okay to reinvent the wheel, and borrow some principles of a concept, rather than embracing the concept that has worked all along?

This is my problem- this argument requires you to be very soft on terminology and definition. It requires you to be flexible with the term “Class”, and although you never see a “Class” in Drupal code, you are supposed to derive what a Class means in Drupal code.

The implications of totally ignoring a specification are that you have to define a new specification in its place- which I’m going to go on the record as being totally okay with. However, there is a caveat to the previous statement- if you are going to create a specification, the freaking specify it!

I don’t know why Drupal documentation has to be so horrible, but it really is. Its the worst canon of documentation I’ve ever come across, and I’ve read through tons of technical documentation. The level of obfuscation is extremely high in Drupal documentation, and the obtuse-ness of it makes it very difficult to penetrate, no matter your technical sophistication.

Even in the multitude of books I’ve read about Drupal, I’ve never gotten a clear, perspicacious look at the Drupal core in my countless hours of study.

So, since I’m complaining so much, I’m going to resolve to do something about it. I’m going to routinely post new facets of the Drupal nebula that I learn about during my tricky navigation of the treacherous waters of the Drupal code base, and hope that those who are totally lost will find some of this content as a beacon to guide them back to the shores of sanity.

Oh, and as one final quip to Drupal- This site is running WordPress, simply because Drupal is such a bitch to customize.

“First learn to use this…. then I’ll teach you to learn this.”

The first “this” in the statement is the mind.

While I’m not arrogant enough to say I know how to fully use my mind, I’m willing to concede that given my level of education, I have harnessed my mind in ways that others have not.

The second “this” is the sword–something I’ve always wanted to learn to use.
So I started using my first this (my brain) and I began researching ways of learning the second this (the sword). I found some really cool links and organizations out there that are dedicated to the second “this”, because they realize the importance of the first “this”.
To be a Warrior–its to be trained in mastering your fear, and to be willing to put yourself in danger, even if it seems foolhardy. The only temperance for the warrior is his mind, something that has to be cultivated, nurtured, and allowed to flourish.
When we learn to use our first “this”, our second “this” is much more powerful.

Git SVN and Microsoft’s dot-blank-x file format

These are a real pain to get working together.

 

SVN is the real culprit here, though. Apparently, SVN wants you to tell it when it is dealing with by setting the mime-type of the file:

 

svn propset svn:mime-type application/blah filename

 

I don’t know about you, but in my opinion, is it too much to ask to have your SCM Manage whatever files you throw at it?
I don’t know, nor care, if this was fixed in a future version of SVN. I think its just yet another argument for Git.

Some might say that git svn should support this feature, the ability to set mime-types in files like svn does. My question to them is- why? If its broken, and a broken element of SVN, then why should git svn support brokenness?

None the less, a work around I have found is just to pull the offending directory locally via svn and then locally make it a submodule with git svn. Its happy then.

Help A Family.

The Internet is an awesome and simultaneously frightening place.

However, I truly believe in the power of the tubes to connect people in need to those who can help.

A friend of a friend is trying to care for their child, who was born with pretty much every disadvantage you can think of.

Please read their story and donate. Most importantly, pass this along to others who you think could help.

http://bit.ly/hwyGMK

hieronymus

https://github.com/larquin/hieronymus

I love XMPP. Its brilliant.

And, I love me some Clojure. Its brilliant too.

So I thought, “Why not craft a Connection Manager for XMPP implemented in Clojure?”

And <POW!> Hieronymus (Bosch, get it?) was born.

Check out the github page above for any and all updates….

GChart Plugin

Lately, I’ve beenĀ  extensively developing a BI Platform for my current project, LAMHDI.

Being the lazy programmer I am, I have tried to implement a variety of charting libraries for data visualization in this specific arm of the project, to no avail.

This isn’t to say that I haven’t found the variety visualization libraries in javascript useful and/or meaningful in my current efforts, rather, I feel that a majority of them are designed with dfferent use cases in mind than the particulars of this project.

It seems to me that a great majority of the plugins devoted to data visualization do so with an after thought for true interactivity, and so I have decided to throw my hat in the ring and write my own javascript library with just this purpose in mind.

Updates will follow here on my blog. If you’re interested, please take a look!

thanks,

m.

Leinengen and Clojure- Taming a beast.

This weekend I was working on a project (that I hope to release relatively soon) and found myself stumped, as a clojure beginner, on how to actually build and run a project for Clojure using the Leinengen build tool.

While “Practical Clojure” and “Programming Clojure” are awesome books, its unfortunate that they were published before wide spread acceptance and usage of the Leinengen tool.

That being said, I found some decent resources that will give you a leg up if you’re like me, and you need stuff spelled out for you some times (go figure).

http://alexott.net/en/clojure/ClojureLein.html

http://blog.carsoncheng.ca/2010/06/building-clojure-projects-with.html