Posts Tagged ‘Programming’

« Older Entries

Where Do We Draw The Line On Complexity?

Thursday, April 16th, 2009

I’ve got a few posts planned about AI and HCI, however these require a lot of time to research and write code for, time that I don’t have given I’m flying to the US on the 21st of April. So I apologise to people who saw my last AI article on Hacker News and Reddit and subscribed to my feed expecting more of the same. There will be more, I promise. I just need more time. For now, just some musings.

I’ve been thinking a lot lately about solving problems. I read a number of programming aggregators and startup blogs, and the term “solve a problem” keeps nagging at me. To be successful, at programming and business, you need to solve a problem. I’d love to eventually run a development company, but I don’t know what problem to solve. So, I consider the problem my current employer is solving.

I currently work for a web development company that is doing fairly well. We have a suite of products that we sell to our clients, and sell services related to those products. They’re doing well, so obviously, they must be solving a problem. So, from “client” point of view, the problem we solve is that of letting people who don’t know anything about websites build and run complex websites.

We have a CMS product that allows non web geeks manage websites. This includes writing new pages and editing content on existing pages, publishing news items, distributing these to an email list, managing uploaded files and inserting modules of dynamic content to their hearts desire. The modules we offer include contact forms, random image rotators, resume upload controls, auto-generating bread crumbs and menus, and so on. These modules aim to reduce the complexity of managing dynamic sites, so that ordinary people can do it.

On top of that, we do custom applications built on top of that CMS site. Clients have a site they run themselves with the CMS, but some also have dedicated applications with a separate interface. These are separate because they’re custom jobs. They provide functionality that is not available in the CMS (yet), or functionality that would be too complex to maintain using the CMS. So again, we’re reducing the complexity of running a custom application.

So, on first looks, we build websites and applications that non-geeks can use. But looking further, we manage complexity. We reduce the complexity for the client, so that the client can do difficult things with ease, and don’t have to know how it’s done, only that they can do it.

On the other hand, good programming is about managing complexity. That is, trying to keep your code as free from complexity as you can get away with while still doing the job. Complex code is buggy and unmaintainable.

Complexity exists, and it is immutable. Once you’ve simplified a task to the point that the only steps involved are those that accomplish that task, and that task cannot be accomplished without those steps, you have your complexity, and it isn’t going anywhere. The task cannot be made more simple, because to do that we’d have to leave out steps, which would not accomplish the task.

What we do from then on is delegate complexity, shift it around and make it other people’s problem. Take for example, the task of creating and publishing a blog post. Our software has tagging, categories, post titles and post content. Creating a post involves writing a post, giving it a title, adding tags, selecting categories and publishing it.

Breaking it down, we need to create a body, create a title, create all categories, create all tags, link the tags to the post, link the post to the categories and publish it. Each link has a display name and a URL slug, and each category has a display name and a URL slug. URL slugs cannot contain certain characters, however their display names can.

Now, we can delegate this complexity to the user, which will result in simple code. The user will be responsible for creating tags and categories, and giving them URL slugs that fit our rules, while the application will just take the data and store it, and retrieve it when asked. The user will be responsible for assigning tags to the post and the categories, and the application just stores it. This is obviously an unacceptable level of complexity for the user.

We could also delegate all the complexity to the application, making the user experience simple. The user just types in the tags they want, picks the categories, and the application will link the tags if they exist, create them if they don’t, automatically strip unwanted characters from URL slugs and hide a lot of the complexity. In more complicated cases, this will result in very complex code that will be bug prone.

So the question is, where do we draw the line? What balance of code complexity and user interface complexity is successful? I guess you could say “make it 50/50″ and think that’s good enough, but I don’t agree. I think the balance is very contextual, and often leans in favour of code complexity. In simple examples like above, taking on all the complexity of the task in the code is a trivial thing and easily done. For nuclear reactor control software, things might not be straight forward.

This is the key to a successful software product/business, I think. Finding the right balance between complexity. If you put too much complexity on the user, user’s won’t be able to use it, and your software won’t sell, and the whole thing will bomb. If you put too much complexity on the software, it will be buggy and difficult to maintain, and will eat up development time and money, and possibly even end up costing more than it earns, and then it will bomb. That’s not even including the more personal aspects of programmer job satisfaction and sanity.

Success is finding the sweet spot when balancing complexity.

Tags: ,
Posted in Editorials, Programming | View Comments

In Defense of the Jerk

Sunday, March 29th, 2009

Not just any jerk, but the jerk who knows his stuff. The technically strong, socially weak programmer who does not play well with others.

During a recent employee review, I was told that I need to work on a few areas, namely the way I communicate with my co-workers, and my tendencies to shoot down ideas without supplying alternatives. I was also told that my technical proficiency was more than sufficient.

The technically capable but socially awkward programmer is a cliche in every day society, and the rogue programmer is a cliche in development teams. Seth Godin’s post, and another one that cropped up in Hacker News reminded me of this, and made me think. I realised that, to some extend, I am that jerk.

The point of this isn’t to toot my own horn, rather to try to offer an explanation on behalf of all well-meaning jerks in software development teams. Now, I’m not talking about those jerk jerks, who code maze-like code to secure themselves a job, those who are needlessly rude and abrasive, and those that ignore the other members of the team to the detriment of the whole project.

I’m talking about the jerks who are otherwise good employees. We’re not trying to sabotage the project, to exert our will over the project, to make anyone feel bad or insufficient.

We just care about the code.

At least, I do. I care about what I’m doing. I care about the project. I want my code to be the best code I’ve ever written, I want this project to be the most successful project the company has. I own my code, and take pride in it.

When somebody suggests something that I know won’t work, that will negatively affect the quality of the code, I freak out, somewhat. The first thing on my mind is to shoot down this idea, because I don’t want it reducing the quality of the project.

If my manager is planning on putting another programmer on the project with me, and I don’t believe they’re quite up to standard, I’m going to try to limit the damage they do to the application. I’m going to try and push them to work in a relatively isolated corner of the application. Unfortunately, I know this is a bad team work based attitude, however I can’t help it.

Now, I’m not defending jerks. Being a jerk is a bad thing, I know this. I agree with what my boss said, and agree that I need to work on these areas. However, instantly firing the jerk, if they’re a well meaning jerk, is not a good idea, because you’ll lose someone who is passionate about what they do, and constantly striving to improve them.

Instead, just try to work things through, and soften the edges of the jerk.

Tags: , ,
Posted in Editorials, Programming | View Comments

Apps Hungarian is Just Good Naming

Saturday, February 7th, 2009

Hungarian flag

Application Hungarian is just good variable naming convention, but worse, because it’s needlessly concise, and hard to read at a glance. It also comes from an environment that is growing more and more obsolete. More on that in a bit.

Firstly, clarification is needed as to the definition of Application Hungarian notation, as opposed to Systems Hungarian. All of this is relatively useless, however, if you are in the same situation I was in a few years back and don’t know what Hungarian notation even is.

Hungarian notation is a variable and function naming convention where you add either prefixes or suffixes to names. What these prefixes/suffixes mean depends on what type of Hungarian notation you’re using. Systems Hungarian is the method of adding information about the type of the value of a variable, or a return from a function. For example, a string that represents a name would be called “strName” using Systems Hungarian. Applications Hungarian is where you add information about the semantic meaning of the value of a variable.If this is a little foreign, that’s because most people think Systems Hungarian when they think about Hungarian notation.

In Making Wrong Code Look Wrong, which is what inspired this post, Joel Spoelsky outlined exactly what Applications Hungarian notation is, and why it’s so useful. He outlines that in Applications Hungarian, you add information about the semantic value of a variable/method return. To illustrate, he demonstrates that you can use Applications Hungarian to differentiate safe and unsafe strings in a web application environment. He uses the prefix ‘s’ to define a “safe” string, that is safe against XSS attacks (ie: A html encoded string). He uses the ‘us’ prefix to define an “unsafe” string, that is a string read directly from user input that may contain potentially dangerous code.

Spolsky also demonstrates using the notation to make wrong code long wrong. That is, by combining prefixes on methods, based on their return types, you can use the names as a sort of litmus test. So if the return prefix of a function specifies it returns a ‘us’ or unsafe string, and you assign it to a ‘s’ or supposedly safe function, this is clearly a logic bug, and looks wrong.

I think this is great, and it’s something I’ve never thought of, but my question is, how is it different from properly descriptive variable naming, aside from it’s somewhat obscure brevity?

The virtues of clear, descriptive names in programming have been sung again and again. If you make your variables and method names descriptive enough, your code becomes somewhat self documenting. You capture the intention and meaning in your code when you use variables like “customerFirstName” and “formatAddress”. You look at those names and you can immediately see the intention behind the code.

I see a huge overlap between the best practice of descriptive variable naming and Spolsky’s intention behind his use of Apps Hungarian, so much so that I don’t see a difference between the two, with relation to their purported goals. Apps Hungarian is more terse, and more obscure, and has somewhat of a learning curve if you’re not familiar with the nomenclature of the system. This, to me, seems like a needless barrier to understanding.

Am I missing something? Why is Apps Hungarian better than regular, descriptive and intelligent variable naming? I can’t see any benefit to using Apps Hungarian explicitly, and to my understanding, Apps Hungarian is just a more terse method of good variable naming.

Tags: , , ,
Posted in Editorials, Programming | View Comments

Frameworks Make Reading New Code Hard

Sunday, January 25th, 2009

In an effort to increase my knowledge of both Ruby and Rails, I have been keeping my eyes open for interesting Ruby/Rails apps to peek at the source code of. Whilst looking at @j_stirk’s website, I noticed it was running on Radiant CMS, a Ruby CMS. So, I grabbed a copy of the source code.

Whilst I was having a peek at the source, I began to think that I was in a little over my head. I managed to muddle my way through the config/routes.rb file and figure out (with judicious use of Google) what requests were being directed to what controllers. The problems started happening when I hit the controller, and started seeing filters and symbols and statements that I didn’t know where to go next to find out about.

Confusion

At first I thought it was to do with the fact that I don’t really know Ruby. I know enough to recognise it, and muddle through basic syntax, but I don’t know any tricks, any coding conventions and the nuances of Ruby programming. However, upon reflecting on my dilemma, I realised this isn’t something that was restricted to Ruby, Rails and Radiant CMS.

I remember last year looking into Symfony, before deciding that PHP was too god-awful ugly to waste my time on. I recall that too had a fairly high learning curve, and looking through an existing Symfony app, it was very hard to figure out what exactly was going on. There was much API browsing.

A few years ago when I first learnt ASP.NET, I was in a similar situation. Server tags and user controls and page events and assemblies were all very new and very confusing to this ex-PHP & ASP 3.0 developer. I stormed through a book on ASP.NET and was thrown head first into a contracting gig before catching my stride again.

I love frameworks. Ever since I heard about this thing called “Rails” a few years back, and realised there were a few similar frameworks written in PHP, I’ve been in love with frameworks. And I’ve always learnt them from the ground up, creating my own application. Last night was the first time I’ve ever tried to learn a framework from an application.

And it’s hard.

While frameworks increase programmer productivity and make maintenance easier for programmers who already are in the know, they make things really hard for a new maintainer who is not familiar with the code to dive in and figure out what’s going on. Not only do they have to learn the individual nuances of the programmer who wrote the application, they also have to figure out how the framework works.

Tags: , , ,
Posted in Programming, Ruby | View Comments

Reconciling YAGNI With Reversibility

Thursday, January 22nd, 2009

Yesterday I started reading Andrew Hunt’s The Pragmatic Programmer, which has been sitting around waiting to be read for at least several months. Every programmer I talk to says that it’s a book that will really stimulate growth as a programmer, and I certainly need to grow.

Already several of the things the author has said have rung true, and I can see many of the scenarios he’s described as having happened, or nearly happened, in a few of the projects I myself has been involved with. Which is exactly what has piqued this post.

Hunt outlines the need for what he calls reversibility. He states that there are critical decisions to be made in each project, and each of these involves a commitment that often isn’t easily changed, such as committing to a type of database, or committing to a design pattern.

Cat in a Box

He goes on to describe the need for a Schrödinger’s Cat approach to software design. The basis is the Schrödinger’s Cat theory which illustrates quantum superposition – where at the point of a decision, multiple dimensions spawn off and you don’t know which dimension you’re in until the decision is observed.

Hunt argues that we should design code to be flexible enough to allow as many of the “possible dimensions” as possible. What he means by this is to allow for these critical decisions to be changed, with minimal impact on the code, hence the term reversibility.

To do this, we should code for possibilities. We should always keep in mind what might happen, and design our software so that we can accommodate the change. This flies directly into the face of another principle of programming, You Ain’t Gonna Need It (YAGNI), and the general belief that the more code you write, the more opportunity there is to introduce bugs in code (something Hunt himself mentions).

YAGNI outlines that you shouldn’t write code you don’t need, and cites several reasons why, and coupled along with the idea of writing less code is better, this is something I believe. However Hunt’s Reversibility idea is in almost direct opposition – he advocates writing code “just in case.”

Can these two ideas be reconciled?

I believe they can, and it’s an approach I’ve used in the past. I’ve found that it’s possible to quickly and safely recognise that there is the possibility of a change by writing interfaces and method stubs for new functionality, and have them throw not-implemented exceptions.

This way, you acknowledge that a decision might be changed and have already got the application hooks to hook into it, but you haven’t wasted time implementing something that may not come to pass. Your software will build, and at the existing functionality won’t be broken while you wait to implement these new changes.

This seems like a trivial thing to do, however it can really streamline the process in my experience.

Tags: , ,
Posted in Editorials, Programming | View Comments

AI Application Programming – Book Review

Monday, January 19th, 2009

I’m spending a lot of my time lately reading about AI, both game related, business application related and academia related. Having recently completed “AI Application Programming” by M. Tim Jones (Charles River Media, 2003, First Edition), I have decided to review it in the context of my current situation.

I am new to the field of AI, and my previous reading has been limited to sporadic Wikipedia research on concepts as I come across them. This book covers a lot of material that I haven’t read about before, but it also covers some material I have. This allows me to evaluate the book as both someone with prior knowledge, and someone with no knowledge.

Firstly, the book was a fairly broad overview on integrating aspects of artificial intelligence into application development. Therefore it was no surprise that a majority of the AI concepts discussed were optimization oriented. The book provided an overview of the history of AI, then it covered simulated annealing, adaptive resonance theory, ant algorithms/ant colony optimization, neural networks, genetic algorithms, a chapter on using some of the techniques described to run artificial life simulations, rules based systems, fuzzy logic, bigrams/Markov chains, agent based software and a wrap up the future of AI.

Each chapter is fairly formulaic. It starts with an overview of the theory of the subject for that chapter, and the presentation of any relevant formula. Then a basic example is covered, without code, in order to show how the theory being covered can be applied. Then a specific example with C source is covered, with a detailed explanation of what’s going on. I largely glossed over the source, as I don’t really have much familiarity with C, so cannot comment on the quality of the source.

Overall I have mixed feelings about the book. A lot of the topics have domain specific language, such as referring to parts of algorithms as genes and candidate algorithms as chromosomes in genetic algorithms, and I feel the author sticks to these to the detriment of comprehension of the topic. For example, the author was discussing “energy” and “temperature” with relation to simulated annealing, without outlining that it’s goal was to narrow the search space for a solution to a  given problem.

Another detracting factor was the numerous errors in diagrams, equations and the text. These errors can be attributed to a variety of sources, from poor copying jobs on some of the diagrams to bad editing. One particularly annoying error was the diagram showing how a NOT logic gate could be constructed using a single neuron neural network – the diagram showed an input bias of 1, with a weight of 1 on the input, claiming that the output will always be the inverse of the input, by the equation output = input * input weight + bias.
An input of 0 into this equation will indeed output a 1, however an input 1 will yield 2, which is incorrect. The correct diagram should have a input weight of -1, which will yield a correct answer with both the 0 and 1 inputs. These errors hindered the understanding of the topic.

However, it’s not all bad news. From my personal reading, I had always struggled with how the back propagation algorithm in neural networks worked, and this book managed to successfully explain it. A lot of the other topics, such as fuzzy logic and the rules based system were also well presented and relatively straight forward.

From reading this book, I feel I have a solid enough understanding of the basics of the topics covered that I could successfully go out and perform my own, more in depth research and succeed fairly well, as well as integrate a few of the more rudimentary features of these approaches into an application.

Tags: , ,
Posted in Artificial Intelligence, Book Review, Editorials | View Comments

Don’t Get the Wrong Degree

Sunday, January 4th, 2009

I recently read an interesting post that popped up in my feed reeder on Saturday night, on a subject that strikes very close to home. Obviously I am not in the exact same situation; I have a degree.

But I have the wrong degree.

The Software Engineering degree I studied was very heavy on the management side of software engineering, and light on the actual implementation side of programming. I don’t know if this is common to SE degrees, however I found this was the case with mine.

I share Daniel’s love and thirst for information, and have a very strong drive to learn as much about everything as I can. So, on the surface, the dilemma of not having the right degree seems fairly harmless. Daniel describes the phenomena of “perception is reality” – people perceive that having a degree is better than not having a degree. So I guess I have a head start in that aspect. I have the piece of paper, I don’t have to deal with these negative perceptions.

Instead, I had to deal with the mistaken belief that I was more competent than I was.

I have never worked in a large company. The company I’m with now is the largest company I’ve ever been with, and we only have 4 developers, including myself. I’ve always worked with smaller companies, that either only dabble in programming, or were start-ups. It wasn’t until I looked at a job posting at a larger company that I realised that I may have made a huge, 3 year long mistake.

The job posting was your standard outline of positional requirements and expected experience and education, but it also had a puzzle attached. You had to complete the puzzle, in your language of choice, and submit the code along with your resume for consideration. This was in late 2006. I can say now that it was a simple graph problem, finding the minimal spanning tree of any given graph. Back then, however, I thought it was just an odd puzzle.

I didn’t know this was a class of problem. I didn’t know this was rooted in mathematical theory, I didn’t know there were algorithms for solving this. I charged head first into solving the puzzle blindly. I ended up with a 90% complete solution that came very close to Prim’s algorithm. I submitted my crippled solution, and naturally didn’t get the position. Later, someone pointed out what class of problem it was, and I was off searching for it.

That’s when it hit me.

That’s when I found out how little I knew about my craft.

Since that day, I’ve regretted every year in that software engineering degree, every year I learnt things that I wasn’t interested in (management) that I could have spent doing computer science. If I could afford it, and if I could afford the time off, I would go back, start fresh and do a computer science degree. However, the more I learn, the more this desire fades. But there is not a day that I do not strive to fill the gaps in my knowledge myself.

I’m not bashing Software Engineering. I know it was my fault for not properly researching the course material offered, I know that I could have gotten what I missed from another institution. The only reason I know this, however, is because I learnt enough about the industry to know what I was missing, and subsequently, know what I needed. And that’s not something every potential high school graduate looking to get into programming will know.

It’s not enough to get a degree – you have to make sure you get the right degree, from the right place. Unfortunately, that generally takes more experience to judge than you have right out of high-school.

Tags: , , ,
Posted in Editorials, Programming | View Comments

Passing Parameters in Actionscript

Monday, December 29th, 2008

While in the process of trying to learn Python, I decided it would be a good idea to attempt to learn some AI and AI related concepts at the same time using the PyGame framework, as advised by AIGameDev.

For a while, I’ve had this really nice steering demo/white paper in my Delicious account, something that I’ve meant to try implementing myself. Because this was entirely new territory, and I know my physics/math isn’t up to scratch, I decided to try to implement some of the behaviors outlined in the previous paper in Actionscript 3.0 first, then when I got the hang of it, port it to Python.

After about 8 hours or so, I had finally puzzled out the seek/flee behavior, and tried to put together a demo as in the above page, when I hit a strange bug. If I put the seek behavior vehicle on the stage on it’s own, it performed correctly. If I placed the flee behavior vehicle on the stage on it’s own, it performed correctly. If I had both on the stage at once, they freaked out and opposed one another, and the two vehicles often got caught in a state of equilibrium, their velocities canceling each other out.

It seemed as if my little vehicle views were sharing the same vehicle model, and the two different behaviors were acting on the same vehicle model. Which didn’t make any sense, considering they were two separate instances of the same class.

After a lot of bug testing and fiddling around, I finally realise I had been caught by the way Actionscript passes parameters into functions/constructors: unless you’re passing a primitive data type, Actionscript passes by reference.

I was instantiating my vehicles with the same velocity and starting position, and I was using arrays to pass in this information into the constructors, little knowing that the actual array each class was manipulating was the same array.
You can easily bypass this by importing

mx.utils.ObjectUtil

and using the

ObjectUtil.copy

method (remembering to cast it back to your desired data type, in my case an array).
So, if you find your instances seem to be sharing private variables they shouldn’t be, check your parameters and make sure you’re not passing things by reference to multiple instances and manipulating them.

Tags: , ,
Posted in Flash, Programming | View Comments

First Impressions Of Ruby

Saturday, December 20th, 2008

I like it.

A lot.

But I always knew I would. I’m so far impressed with how much effort Ruby goes to at making itself understood at a casual glance, and just how easy it is to write self documenting code. Writing code that’s free of braces and parenthesis is refreshing, and it’s nice to know the safety blanket is there (with regards to parenthesis for functions, conditional statements, etc) is there if I need it.

I started last night by flicking through Why’s (Poignant) Guide, and found it pretty good for the basics. I quickly picked up the general concepts and basic syntax fast, and Why’s Guide was pretty whimsical and kept things interesting. However I quickly bored of the absurdity in chapter 5 where the majority of its content is fluff.

I tried switching to SaphireSteel’s The Book of Ruby, however right at the start when the author stated:

if (subtotal < 0.0) then subtotal = 0.0 end

Putting everything on one line like this adds nothing to the clarity of the code, which is why I prefer to avoid it

I knew that this book would not help me. I already know many languages that require simple statements like that to be spread over multiple lines. I want a language to do this:

subtotal = 0.0 if subtotal < 0.0

Hi, Ruby.

Then I browsed over to Ruby in 20 Minutes and quickly flicked through the pages, and it concreted my knowledge. I like iterators, I like respond_to?, I like how everything seems to make sense. I also am pleased to see how many concepts map onto similar things in C#. Modules are like namespaces, but better. attr_accessor is like { get; set;}. attr_reader is like {get; private set;}.

I feel I’m ready to go find some code in the wild and attempt to read it. I’ll also see if I can come up with a post that maps Ruby concepts to C# concepts for other C# programmers interested in Ruby (and with IronRuby, there’s no reason why you shouldn’t be).

Tags: , , , ,
Posted in C#, Languages, Programming, Ruby | View Comments

Ruby & Python Bootcamp

Friday, December 19th, 2008

It’s common advice in the programming industry to learn one new language every year to stay on top of things. It’s something I honestly believe in as well. Unfortunately I can’t say I’ve learnt a new language this year.

Last year, I learnt Actionscript 3.0, which is different enough from Actionscript 2.0 to be called a new language. I did this because of work, I did it in December and I had to do it fast. That worked pretty well for me. I got thrown in the deep end and had to learn or drown.

This year, with this being my last day at work for 2 weeks, I’m going to do the same thing, but I’m going to make it a little more interesting. I consider myself a reasonably competent programmer, and fairly solid in my knowledge of OOP paradigms. I think I can learn a language pretty quick. So, during my holidays, I’m going to:

  1. See how fast I really can learn a language at least to the point where I know what to search for online and can find my own way around reasonably confidently.
  2. See just how easily various concepts from different languages transfer across syntax
  3. Build some stuff I’ve been meaning to build for a while but kept putting off

With that in mind, this year I’m going to learn both Ruby and Python in 2 weeks, dedicating a week to both languages. In the process of learning these languages, I will also build a base for 2 websites for 2 of my domains that I have been meaning to build. I won’t spend any time designing them, just building the code.

So, over the next 2 weeks, the majority of posts on here will be reflecting my thoughts on Ruby and Python, and linking to resources that I plan to use in my learning, with a final post being the unveiling of the websites I manage to build.

Wish me luck!

Tags: , , , ,
Posted in Languages, Programming, Python, Ruby | View Comments

« Older Entries