Lazycoder.com - Part 2

Pros don’t make do

23-Nov-09

I had a locksmith come out to replace a doorknob that had gone bad. It had gradually gotten hard and harder to turn and finally the bolt got stuck inside the door. Which meant the only thing keeping the door shut was the deadbolt. I had replaced doorknobs before, but this one had a non-standard length and strike plate so I didn’t want to mess with it. The thing that struck me while watching him work is that he never had to try and force a tool to do something it wasn’t designed to do. He always had the correct tool and it worked exactly the way he expected it to. He never tried to screw in a Phillips head screw using a knife blade or a flat head screwdriver. He didn’t have to duct tape anything

I have a small battery powered Dremel rotary tool. It works for very small jobs. There have been a couple of times when I’ve had to push it way beyond it’s limit, including once when I needed to make the opening on a door jam for a strike plate a little wider. It took me forever. I had to charge the battery twice and broke a bit before I finally had enough room, but just barely enough room. Contrast that with the locksmith who had to do the exact same thing. He pulled out a much larger Dremel that plugged into the wall. Where it took me almost 45 minutes to rout out the door jam, he took about 2 minutes with his much more powerful tool. I could have stopped, went to the store, and bought a more powerful tool and gotten the job done much faster. But I thought that this tool would do the trick and going to the store would have cost me some resources, it might have taken a little longer. I’d have to learn how to use the new tool. Get a new bit. But overall, it probably would have saved me some time in the future and probably would have saved me some time on that project. I could definitely find other uses for the new tool.

Think about that the next time you reject a new programming tool because you think it might take too long to learn or it’s different. Instead of doing the hacky way you KNOW will work, check to see if there is a more elegant or permanent solution. Because if you aren’t careful, your cheap and easy workaround might end up sticking around in the project long enough for it to become a problem to you.

Share and Enjoy:

Filed in General | | Comments (10) »

We need a language for programmers

17-Nov-09

Here is a great rant about “modern” programming languages.

And so for 20 years now these folks —
*the* shining lights, in many ways, of “practical” programming
language, operating systems, and general systems research — have
continued to fail to “get” the fundamental practical needs of everyday
programmers working in The Real World. “Go” is just another language
written first for the compiler and only secondarily for the programmer
— and stuck in a 70s mindset* about the relationship of that
programmer to the (digital) world within which they live and work!
(But hey, it compiles fast! Which is, of course, THE problem that
really needs addressing.)

He then goes on to talk about some aspects of languages that frustrate him.

J.H.C, folks, it’s nearly 2010. Let’s get a few things straight:

– most programming involves schlepping a few but complex data types
between different string representations
– programmers have become plumbers and documentation-archaeologists
mostly, which is sad and uninteresting
– programming languages are for *programmers* — not compilers and
compiler-writers
– until you make the everyday, “simple” things simple, it will
continue to be a dark art practiced by fewer and fewer
– any language that makes you explicitly import an IO module to
read a file or stdin is fucked
– declarations are a pointless anachronism (same for explicit
memory management)
– if I have to understand category theory to write a program that
does IO, IT IS A NON STARTER!
– less stupid line-noise syntax and punctuation, people

I don’t understand why the need to compile fast is such a big deal. If your programming language makes you write so much code that it takes more than a few seconds to compile, you should probably look at using a different language. Here are some things that I’d like to see in a programming language that is designed for programmers rather than compilers or computers.

1) No typing – That’s not to say that I can’t declare my own types, classes, objects, etc… But that calls to objects should be type independent. (e.g. messaging and dynamic dispatch)

2) Built in unit testing – I should be able to declare contracts on the methods and pass/fail criteria. The tests should be run as part of the compile step or interpretation (if the language is compiled or interpreted)

3) Jellybeans

4) Automatic inclusion of libraries based on path and usage. – I don’t mind having to pull in a library to do file I/O or consume some other kind of data like ATOM or JSON. But at compile time, if I have referenced any of the objects contained in the library, all of the references to the library should be handled for me automatically. Any name collisions should be compiler warnings so I can specify which library to use by in my code or make the reference explicit in some other way. I like Pythons path based module convention, the language should just search the child directories for a library if the library isn’t already included in the base language pack.

5) Anytime a design pattern emerges, it should be re-factored into the language itself.

6) It should be a pocket language, have a set of keywords and syntax that is small and compact but still understandable. JavaScript and C are good examples of pocket languages. It’s easy to pick up the syntax.

I’m sure there’s more that I would add. What kinds of features would you like to see in a language oriented towards programmers rather than compilers?

Share and Enjoy:

Filed in General, Languages | | Comments (17) »

Why should I care about the hardware?

05-Nov-09

I'm not a network engineer. I just build the applications, the network professionals take care of deploying my applications and making sure they stay up. Why should I care about what hardware they use?

Because the hardware they use could influence my application architecture.

If I know the IT guys are able to bring in new servers in response to increased demand, I start to think about distributed caching instead of replication maybe. I start to think that the application shouldn't store any data in a machine specific session so that the load balancer can send the user to any machine.
If they have access to distributed hardware caching, maybe I don't have to worry about donut caching in my pages.
If I know they can pull servers in and out of the clusters at will with no visible downtime to our users, I start to think about deploying more often. I can become more agile.
If I don’t have to worry about how much space is left where I’m storing my users uploads, I don’t have to write code to check how much space is available and present an error to my users if the space fills up.

One of my goals with my F5 Devcentral blog is to explore ways that developers and IT professionals can cooperate more and blur the lines between them a bit more.

Filed in DevCentral Posts | Tagged CrossPostedFromDevCentral | Comments Off

Dependency Injection and Inversion of Control are not rocket surgery

03-Nov-09

I see a lot of people talking about how “advanced” techniques like dependency injection and inversion of control are and how their team won’t understand either technique.

Folks, this isn’t hard. In fact, both of these things are so simple I simply call it “using the programming language”.

Let’s look at dependency injection.

PLAIN TEXT

C#:

public class MyClass
{
private DataTableReader _reader;
public MyClass()
{
_reader = new DataTableReader(new DataTable());
}
private void DoStuffWithTheReader()
{
while (_reader.Read())
{
//do fun stuff with the reader.
}
}
}

See the reader variable? That's a dependency. You have to have it in there to do fun things later on. But we have to create it ourselves, which is one more thing that we have to do in our class constructor. In reality we also have to populate the DataTable. So what if we make the reader variable constructor parameter so that another class can do the work of creating the DataTable and the reader?

PLAIN TEXT

C#:

public class MyClass
{
private DataTableReader _reader;
public MyClass(DataTableReader dataTableReader)
{
_reader = dataTableReader;
}
private void DoStuffWithTheReader()
{
while (_reader.Read())
{
//do fun stuff with the reader.
}
}
}

There, that's better. Now our class doesn't have to worry about creating the reader and the DataTable. This, in a nutshell, is dependency injection. It's not very complicated is it? We've made our class construction a little simpler and if we want to unit test this, we don't have to do any complicated mocking, we can just new up our own DataTableReader instance and populate it with whatever test data we want. If you run into any funny looking data in the DoStuffWithTheReader method, you know that you don't have to look in this class at all to see where the funny data is coming from, only in whatever method is creating this class and passing in the DataTableReader.

Now is there anyone who thinks that developers on their team would have trouble understanding passing in a parameter? Should they really be a developer if they do?
Honestly, it's not that hard.

Ok, so let's look at inversion of control. The original definition of inversion of control I read was by Martin Fowler:

There's a big difference now in the flow of control between these programs - in particular the control of when the process_name and process_quest methods are called. In the command line form I control when these methods are called, but in the window example I don't. Instead I hand control over to the windowing system (with the Tk.mainloop command). It then decides when to call my methods, based on the bindings I made when creating the form. The control is inverted - it calls me rather me calling the framework. This phenomenon is Inversion of Control (also known as the Hollywood Principle - "Don't call us, we'll call you").

If you look at the previous example, you'll see that we have already inverted the control a bit just by using dependency injection. But the class still has a degree of control over WHAT concrete object is created, in this case a DataTableReader. What if we need to switch over to a SqlDataReader or an OleDbDataReader? Well, we could create three other classes that all take the specific type of data reader we might want to use. But that's a bad idea, you end up with the same logic spread all over the place. Instead we can use the IDataReader interface that all three classes implement.

PLAIN TEXT

C#:

public class MyClass
{
private IDataReader _reader;
public MyClass(IDataReader dataTableReader)
{
_reader = dataTableReader;
}
private void DoStuffWithTheReader()
{
while (_reader.Read())
{
//do fun stuff with the reader.
}
}
}

Now our class not only doesn't have to worry about creating the DataTableReader, it doesn't even really care if it gets a DataTableReader at all. All it cares about is that the reader is referencing something that implements the IDataReader interface. This is a type of inversion of control. Most of the time people get confused between inversion of control and a container that enables inversion of control and dependency injection (like Ninject, StructureMap or Unity). You don't have to use a container to utilize these two techniques, it just makes it a little easier.

update:Also check out this great post "It’s all about the delivery"

update: I mistakingly thought it was hard to do D.I. in Python due to the inheritance mechanism in Python. Turns out, it's just as easy.

PLAIN TEXT

PYTHON:

class MyClass():
def __init__(self, dataTableReader):
self._reader = dataTableReader
def DoStuffWithTheReader(self):
while(self._reader.Read()):
#Do Fun Stuff with the reader.
print(self._reader.item)

Share and Enjoy:

Filed in Agile, General, Tutorials | Tagged DependencyInjection, DI, InversionOfControl, IoC | Comments (10) »

Agile practices do not address technical complexity

29-Oct-09

So, first go read Ted Neward “Agile is treating the symptoms, not the disease.” and Phill Haack “Software Externalities” then read the Agile Manifesto

At some point that very simple manifesto turned into a set of “must have” tools, technologies, methodologies, and processes. Which I think defeats the purpose. You have to look at each tool and methodology and think “how does this help me build better software for my user?”

There is a very important paragraph at the bottom.

That is, while there is value in the items on the right, we value the items on the left more.

So let’s go through each line.

Individuals and interactions over processes and tools

These “story cards” are one way to increase the communication between individuals during their interactions. Gigantic requirement specifications don’t do anyone except other software engineers any good. The daily standup meeting that a lot of agile practioners adopt is one way to keep the team up to date and find out about possible problems as soon as possible.

Working software over comprehensive documentation

No matter what, you’d rather have an application that meets the users needs and helps them get stuff done easier than they could before you wrote their application. Chances are, if you need to write a lot of documentation, you’ll have to maintain it also. Most of the time documentation is only for other developers that will have to come along behind you and change the software to meet new user needs. What better way to communicate what the software is supposed to do than a bunch of executable code, e.g. unit/scenario/integration tests, that ensures the application does what it says it can do?

Customer collaboration over contract negotiation

By adopting techniques and tools that allow you to change direction quickly and confidently, you don’t need to “lock down requirements” before you start developing. If the requirements change, you’re code base and tools are flexible enough to handle the change. That’s where principles like S.O.L.I.D. come into play, they make your code base more flexible and responsive to change.

Responding to change over following a plan

How can you ensure that, as you change your software to respond to changes in the business or requirements, your software doesn’t break? Automated testing is one method. Continuous integration builds are another. These tools aren’t used by agile practitioners because they want to feel cool, they are used to help them better respond to change. The story cards and backlog also help. You can re-prioritize your backlog to meet the businesses current needs. Since your iterations are short, and your stories are small, the overall impact to changing direction is minimized.

The fact that software development is complex, and that there is a lot of new things to learn. That there is ALWAYS something new to learn about software development, has NOTHING to do with agile practices. You’d have exactly the same problem keeping up if you practice agile or not. You might have an internal process where you work that allows you to respond to change quickly, it may even involve Microsoft Access!

There was a great post that Miguel De Icaza linked to on Twitter. “Every Ideology is Right”

What I mean by "right" is that is each one is responding to a genuine problem within human existence. And their prescriptions for how to deal with that problem "work," at least in the short term in limited circumstances.

Obviously, there are unforeseen consequences because each ideology looks at a limited aspect of reality, and then tries to apply its solution for that part of reality to ALL of reality. The important thing is to try to have your ideology "look" at as much of reality as possible.

Share and Enjoy:

Filed in Agile | Tagged Agile | Comments (2) »

A theory about the iPhone app store

28-Oct-09

My theory is that in 2 years there will be so many applications in the iPhone app store that it will be impossible to achieve success. That only the early developers will find any measure of success.

I say this because it seems to be the way the Apple software ecosystem works. There are a few applications, written by developers who have been working on the Apple platform for a great number of years, that are constantly recommended and very successful.

Share and Enjoy:

Filed in Apple | Tagged AppStore, iPhone | Comments (3) »

Lazycoder

Pros don’t make do

We need a language for programmers

Why should I care about the hardware?

Dependency Injection and Inversion of Control are not rocket surgery

Agile practices do not address technical complexity

A theory about the iPhone app store

The Lounge

Books I’ve worked on

Hosted By

Contributors

Links

Recent Posts

What I'm Doing...

Categories

Pages

Herding Code Podcast