Archive for category Programming

The Bottleneck

The monk Ahiru was pairing with the bright young apprentice, Taipisuto. The apprentice was quite impressed with his customized editor and the speed at which he could type. Ahiru was not nearly as impressed. The screen was flickering in a way that made him more than just a bit nauseous.

“And what shall you do when you’re assigned to a clan and they use a different editor? How will you pair with them?”, asked Ahiru of the apprentice.

“I shall teach them the vastly superior ways of Emacs”, replied the apprentice matter of factly. “It allows us to type very quickly with almost no effort at all! How can anyone deny this?!”

Ahiru quashed his desire to strike the young man. He appreciated his confidence, but the young apprentice had a lesson to be learned. That night, Ahiru committed the worst of sins. He rebased the clan’s master branch, eradicating the work the apprentice and he had done that day and making it impossible to easily restore it from the apprentice’s local fork.

When the monk arrived the next morning, the apprentice was visibly distraught, his fingers flying over the keyboard in pure desperation.

“What’s wrong?” asked Ahiru, knowing full well what he had done.

“Our commits!”, cried the apprentice. “They’re gone! Someone committed the sin of all sins and rebased the master branch! We’ve lost an entire day’s work! Who can have done this?”, he moaned.

Null.“, said Ahiru. “We’ve simply lost the code. The work has not been lost.”

The apprentice just stared at the monk, not understanding the words he had just heard.

“90% of what we do is think about how to solve a problem, Taipisuto. The temple does not pay us to write code, they pay us to solve problems, and solve the problem we did.” Ahiru slid down into his seat next to the young man. “Now, let us re-implement the code. How long do you think it will take us?”

“It took us all day yesterday to write it…”, the apprentice bemoaned again. This time, Ahiru did not restrain himself and came down swiftly on the top of Taipisuto’s head with his staff.

“Type.”, said Ahiru.

Half an hour later, as the pair were checking the newly re-implemented code into the clan’s master branch, the apprentice was enlightened.

I’m a big fan of The Codeless Code and since they’ve not posted anything new in a while, I thought that I’d try my hand at their style of “programmer’s koan”. Following their lead, the story above is provided under the Creative Commons Attribution-NonCommercial 3.0 Unported License.

Leave a comment

Doing what’s best, even when it sucks

About 8 months ago, I promised you that I’d follow up and let you know how our transition to Agile software development was going. This is that long overdue follow up and I’m sad to say that six weeks ago I submitted my resignation. Tomorrow I start with my new company.

I’m sitting in an airport right now reading Brad Warner’s “Hardcore Zen” for the dozenth time and I think I’m finally ready to talk about all this. I’ve been trying to figure out what to say for over a month. I know I need to write about this, but I’ve not had the words until now. It turns out, that it’s fairly simple.

I failed.

I failed. I failed. I failed. I learned, my team learned, we found an incredible amount of success, then we failed. Then I failed in the worst possible way: I gave up.

Read the rest of this entry »


In Depth on my first NodeJs / Express Stack

The whole goal of my hobby site is to iteratively create the simplest website that could possibly work using all “new to me” stacks. Getting a static site up and running on my own Linux CentOS with Lighttpd was definitely simple. Getting a NodeJs web service up and running with Express was equally simple, but making it production quality was definitely a frustrating experience for me.

My initial experience with NodeJs was exhilarating. I had a web server & app running with just a few lines of code, but then I quickly soured on the whole platform when I found TDD & mocking to be more difficult than I feel it should be. I’m happy to say that through a bit of research and effort, I now have a stack that I’m relatively happy with.  I want to capture the struggles and solutions while they’re still fresh in my mind.

Read the rest of this entry »

, , , , , , , ,

Leave a comment

Initial Thoughts on Node.js

I’ve been building a hobby site so I can learn about non-Microsoft stacks and I spent the weekend learning Node.js. At first I was completely amazed at how awesome it was. It took about 5 minutes to spin up a webserver and start returning HTML from an endpoint! It was easy and fun! That 5 minutes of fun ended as soon as I thought “okay, now let’s write some production quality code”.

I’m not sure if it’s a problem with JavaScript or with Express, but dependency injection is far more complicated than it should be. I like to test drive my code and that means mocking out datasources so we don’t need to hit a filesystem, database, or network. That proved to be extremely difficult with Express’ `require` system. Requiring an external module basically hardwires you into that dependency, which is a no starter when you need to fake that dependency. I wasn’t able to get a constructor for the route working properly, so I ended up settling for keeping my requires in my `server.js` file and using property injection. Ugly, but it worked.

This ugly solution was bothering me, so I dug my heels in and went searching for a more idiomatic way to accomplish DI. What I found was Proxyquire. Proxyquire isn’t really DI. It works much in the same way you’d break a C `imports` dependency by creating a fake and telling the linker to use your fake instead. Only, of course, Proxyquire does this at run time instead. The documentation is good, but not great and it took about about an hour to get it working properly. It was a rather frustrating experience.

So, with a way to fake dependencies in hand, I get to writing an actual assert statement. That’s when I hit the next wall. Express’ way of sending responses doesn’t actually return anything. It all works via side effects. So now I could go install Sinon and learn a 4th library or I could just not write the tests because I’m not having fun anymore. Wasn’t that why I fell in love for that brief moment? Didn’t I love Node a few hours ago because it was easy and fun?

That doesn’t mean that I don’t have a use for Node.js though. I would absolutely use it to quickly prototype an idea. It’s completely fantastic for getting something simple up and running quickly. However, I would then just as quickly throw that prototype in the trash and write my production code in something else. A platform being quick, fun, and easy doesn’t matter if it’s hard to do things the right way. If it’s easier to write tightly coupled and untested code, we will. I don’t know about you, but I like knowing my code works and will continue to work.

Before I tried Node.js, all I could think was why would anyone want to use JavaScript for their backend. After a few days of learning it, I’ve found a use case, but am still left with a sour taste in my mouth. Maybe I’d be less disappointed if I hadn’t had a moment early on where I fell in love with it. Granted, there’s no way I learned the idiomatic way to write a Node web app in a few days, but I just can’t see myself ever using this for a production application. If you know of any good alternatives to Express that make testing Node code easy, please let me know in the comments. I hate to write off such a fantastic platform prematurely.



Complete Guide to Setting Up a Secure Website on a VPS with Lighttpd

Last time I talked about setting up a simple web server and site from my phone. Since then, I’ve been spending a little bit of time getting things set up right. That’s been a bit more challenging than simply getting the thing up and running, so I figured I’d take a moment to jot down some notes in case I ever need to do this from scratch again.

Read the rest of this entry »

, , , , , ,

1 Comment

Building a Website ON an iPhone

There’s a lot of information out there about building websites for mobile, but have you ever considered that it’s completely possible to set up a website from a mobile device? I did just that today. 

A few days ago, I received an email notifying me that an old domain of mine was set to expire. I haven’t had it hosted in years, but didn’t want to let go of the domain. I was tossing around the idea of setting up an old desktop as a server, but I’d like to eventually migrate this blog to the domain and an old desktop on a commercial ISP probably wouldn’t handle the traffic very well. A friend of mine recommend a VPS (virtual private server) instead. It sounded like a great way to get to know some different stacks and I planned to set things up a few weekends from now. 

Over coffee this morning, I logged in to renew my domain and pick out a hosting company on my phone. Before I finished my first cup I had not only accomplished that, but already had an SSH session to my shiny new instance up and running in my mobile’s chrome browser. It was a bit awkward, so I did a quick search on the App Store and found the Reflection SSH client app. Much better. This app was nearly as good sitting at my desk typing in a Putty terminal. Within a few minutes, I had a new user setup. 

I went for a second cup of coffee and thought, “How far can I push this? Can I set up a webserver from my phone?” A quick search led me to this great tutorial about setting up a webserver on Linux. I followed along through some basic server  setup and everything went smoothly right up until I tried to actually install the Lighttpd (“lighty”) webserver. Lighttpd isn’t listed in the CentOS repositories, so I needed to manually download it from a mirror. Typing in that URL was not fun, but all in all, not hard. It was just awkward typing it on this tiny touch screen. It’s odd, I can easily type entire blogs on it, but a URL is beastly to type out on an iPhone. 

A few more google searches and I had the firewall set up correctly and could access the Lighttpd sample site from my phone’s browser. 

Back over to my domain name provider to point my domain to the VPS and my domain name was now routing to my website. 

In about 2 hours, I had a webserver running using nothing but my iPhone. That’s pretty damned cool if you ask me. When I was my daughter’s age, it would have taken that long just to download and install the SSH client!

I just couldn’t resist pushing this absurdity to the extreme at this point. I went back to the App Store and found an SFTP app and an HTML editor. 30 minutes later I had the simplest website that could possibly work. 

It’s not pretty, or fancy, but it’s online and I never touched my laptop. I certainly wouldn’t recommend doing this from your phone if you need to be productive and I won’t be maintaining the site this way, but I find it terribly fascinating that it’s possible. 

, , ,

1 Comment

Retrospective: How We Could Have Failed Faster

For the last several months, I’ve been working on a project that involves reading data from a device via Bluetooth and then sending that data to another machine via RS232 serial port. At least, that’s my piece of the puzzle. It’s proved to be a challenging, but not insurmountable, task for  someone who is traditionally a CRUD programmer.

Yesterday, we discovered that we built the wrong software. I built what I was asked to build, but it isn’t what the client needs. The sensor device that was chosen doesn’t provide appropriate data for the use case. I spent the day salvaging whatever code I could for reuse in the end product, but the application itself (and several months of development) will be thrown away. This has prompted me to have a personal retrospective on this project to see if there were things we could have done to fail faster.

Read the rest of this entry »

, , , , , ,

Leave a comment

ObservableCollection is a Leaky Abstraction

And so is BindingList. Or, rather, exposing them through your controller’s interface is a Leaky Abstraction.

Anyone who’s done any Windows desktop development has eventually come across ObservableCollection and BindingList. How often have you written a controller (ViewModel or Presenter, doesn’t matter what you call it, they’re all some variant of the Controller in MVC) that looks like this.

    public class LeakyWpfController : INotifyPropertyChanged
        public ObservableCollection<Person> People { get; } = new ObservableCollection<Person>();

        public event PropertyChangedEventHandler PropertyChanged;

Or this

    public class LeakyWinformsController
        public BindingList<Person> People { get; } = new BindingList<Person>();

What’s wrong with this code?! We need to expose a collection type that the framework understands for the databinding to work!

No. We don’t. Both Winforms and WPF don’t care what you expose. They only care that the backing field is of the proper type. All you need to expose in your public interface is an ICollection, in both cases. Databinding to these two controllers works perfectly well.

    public class WpfController : INotifyPropertyChanged
        public ICollection<Person> People { get; } = new ObservableCollection<Person>();

        public event PropertyChangedEventHandler PropertyChanged;

    public class WinformsController
        public ICollection<Person> People { get; } = new BindingList<Person>();

Ok, so big deal. It’s not like I’m ever going to use my ViewModel or Presenter for anything but the specific View they were built for…

Are you so absolutely sure of this? If you’re certain that you’ll never want to use the same presentation logic in more than one window or application, then sure. You’re probably right. Leaking this abstraction doesn’t hurt, but what if we wanted to reuse logic from our old Winforms application in our new WPF app? Or what if we wanted to set ourselves up to migrate away from that old Winforms app into a new WPF application? What do we do when WPF and ObservableCollection aren’t the newest, greatest thing anymore and we’d like to migrate to that newest framework? Wouldn’t it be nice to be able to do so with minimal effort?

Our two controllers are at this point so similar, we can combine them into one. (Thanks to the fact that WPF supports BindingList as a backing field.)

    public class Controller : INotifyPropertyChanged, IController
        public ICollection<Person> People { get; } = new BindingList<Person>();
        public ICommand AddItemCommand = new AddItemCommand(this);

        public event PropertyChangedEventHandler PropertyChanged;

I only recommend using BindingList as a backing field if your Controller (view model/presenter) needs to work in a Winforms environment though. There are some performance issues with BindingList. If you only need to target WPF or UWP, then ObservableCollection is the right way to go. Either way, there’s no reason to expose anything more than an ICollection to the outside world.

, , , , , , ,

Leave a comment

IT as Couples Counseling

Do you ever feel like a teenager passing messages between your separated parents?

Joe in receiving puts in a ticket asking you to look into an issue. You take a look at it and realize that it’s because Barb in purchasing failed to check a box. So, you email Barb and ask her to correct it. Barb corrects it and you go back to Joe to see if his issue has been resolved.

Joe says, “Yup. Looks good now. Thanks. This is the 3rd time this week those idiots over in purchasing screwed up.”

“What do you mean this was the third time this week?”, you say.

“Well, I got tired of complaining about it, so it was easier to just put a ticket in. Those asshats know the process, they just don’t do it and it causes us to get behind. I don’t have time to go hunt them down every time they screw the pooch.” Joe laments.

You want to reply, “So you wasted my time on an issue you could have fixed yourself?!”, but instead you just sigh and walk back to your desk, dejected. There was no reason for IT to even be involved in this. Joe could have just called Barb, politely asked for her to fix it, and moved on with his day. He didn’t because he’s angry at them and it was easier to have IT address it. Why not? IT fixes all the problems, don’t they?

We could easily just continue to just deal with the problem as it interrupts us, but that doesn’t address the issue at all. It’s just putting our heads in the sand and saying “Not my job.” If we want to stop playing messenger, then we’re the ones who need to take action. Once a feud between two departments in an organization begins, it’s extremely unlikely that it’s going to end without outside intervention. Like it or not, IT is a neutral party that both sides of the problem trust and it’s up to us to fix it.

Read the rest of this entry »

Leave a comment

The Rocky Road to Agility

A few months ago, I wrote about the beginning of our journey on the path to agility. Since then, we’ve made some major strides and also had some serious set backs.

Our process was getting better, but we continued to struggle with the legacy code base. I was writing tests and refactoring the code base, but was still the only one doing so. The team was seeing the benefits I was getting out of it, but simply didn’t know how to do it themselves.

Read the rest of this entry »

, , , , ,

1 Comment