Always Get Better

Posts Tagged ‘General Programming’

That’s Not My Job

Friday, March 13th, 2015

Most companies seem to have a group of people who gravitate to either front-end or back-end development. I’ve been struggling to wrap my head around this because it doesn’t seem like a useful dichotomy.

It’s a fast-moving field, do you really want to carve a niche as a Unity programmer? An ActionScript expert? A Sharepoint developer? If you specialize to that degree, what happen

s when your technology of choice moves on?

How many of these have you come across:

“Front-end” developers who don’t understand the HTTP stack.

Companies that don’t have centralized source control.

“Back-end” developers who believe front-end code should be unit and performance tested just like server code – who don’t understand why squeezing maximum performance for one user on one machine would be as challenging as constructing a web app that served thousands of users at the same time.

Web designers who don’t know HTML, CSS and jQuery.

Anyone who takes a laissez-faire approach to security.

Project groups that don’t use Continuous Integration.

Understand More

Everyone has an area of interest where they excel and you should definitely pursue yours. Never forget that yours is a piece of the whole, and the more you understand of the whole the better you will be able to create value with your work.

If Photoshop is your bread and butter, learn how programmers slice your designs into HTML. Understand the technical limitations and get inspired by what the web browser can do for you.

If you’ve been slinging awesome responsive webpages, use your JavaScript skills to learn Node.js and understand where that server data is coming from and how it is stored. Expand your ability to write front-ends that scale as beautifully as they present.

If you are more comfortable in the bowels of a Linux server, download Cocos2d-x and experience the thrill your front-end counterparts get when their math turns into gorgeous sprites on-screen.

Everybody’s Talking

Every time you learn something new you open up a world of people you can network with and understand at some level.

Whenever someone asks how to get into the field, what do you answer? “Just do it!”

Rely on Continuous Integration

Friday, April 22nd, 2011

If your testing process involves copying files over to a development environment and hoping you have the most up-to-date version of everything, stop now. There is a better way, and it is continuous integration.

CI works by constantly and automatically testing and publishing everyone’s code into a staging environment. Any missing files or major problems are caught immediately so the team doesn’t run into major conflicts at the end of the development cycle. Although continuous integration does not eliminate code bugs, it improves the software quality by allowing developers to identify and fix problems immediately, resulting in a final product with much fewer defects.

Although there are a lot of different parts to a successful CI process, it is possible to start up slowly and add to the regime as your team becomes more comfortable with their improved success rates.

1. Establish a centralized source code repository
A solid source code manager (SCM) is the backbone of a professional development setup. There are so many tools available for every possible organization, both paid and free. I like git, but Subversion is used in a lot of environments. The key thing to look for is something that can track and rollback code changes over time and is shared between everyone working on the project.

2. Automate the build
After a good SCM has become part of development procedure, automate the build What this means, is every time someone commits to the SCM, have a tool like buildbot pull the fills and deploy them to a testing environment. From this stage on disallow anyone from making changes directly to the testing environment.

3. Automate Testing
Next add unit testing. When the build agent runs the unit tests, it should prevent the source code from going into the testing environment if any error conditions exist in the code. This will let the team make more daring changes to the source code without having to worry about time-consuming reversion testing.

4. Automate Deployment
At this point we’re already have an automated way of deploying our code to a testing area – take it a step further and automate your deployment process. This will let you get your work into the hands of your customers faster and involve them in the planning process earlier – all resulting in an improved product and higher likelihood of staying on-time and on-budget.

A Simple Makefile for the Go Language

Tuesday, January 19th, 2010

Hey folks, it’s been awhile!

I’ve been playing with Google’s Go language, and will be sharing what I’ve learned over the coming weeks.

First off, which seems like the easier way to compile your source code? This:

6g fib.go
6l fib.6
mv 6.out fib

or this?


Personally, I prefer using a Makefile, even for a small project with one source file.

Without further adieu, a simple Makefile for the Go Language:

GC = 6g
LD = 6l
TARG = fib

O_FILES = fib.6

make clean
make $(TARG)

$(LD) -o $@ $(O_FILES)
@echo "Done. Executable is: $@"

$(O_FILES): %.6: %.go
$(GC) -c $<

rm -rf *.[$(OS)o] *.a [$(OS)].out _obj $(TARG) *.6

VISTA: How to fix SQL Server Express Error – CREATE DATABASE permission denied in database ‘master’

Thursday, November 5th, 2009

If you’re using SQL Server Management Studio Express under Windows Vista and see either of these errors:

CREATE DATABASE permission denied in database 'master'


The database [Name] is not accessible. (Microsoft.SqlServer.Express.ObjectExplorer)

Here’s the fix:

  1. Close SQL Server Management Studio Express
  2. Open your start menu and locate that program.
  3. Right-click on the Management Studio and choose ‘Run as Administrator’
  4. Fixed!

I swear the simplest solutions can be the hardest to find – hopefully this saves someone (or my forgetful self!) some aggravation.

People Cost More Than Equipment

Tuesday, December 30th, 2008

Much of the professional world has switched over to a two-monitor setup. I can’t even begin to imagine how I ever did with just one since I am now so used to having a help or a search open just outside of my main viewing area. Having reference material in my peripheral vision but accessible just by turning my head is much faster and less disruptive than having the fumble around the task bar and switch the focus of my attention.

It is said that switching tasks takes time – some users report productivity reductions of up to 15 minutes each time they have to change their focus of attention. If a programmer has to look at the documentation only once per day, their employer is looking at 1.25 hours of lost productivity every week, which may not seem like much but when extrapolated to that person’s yearly wage (averaging at $78k) the cost of the lost productivity is worth approximately $2400; much cheaper to buy that $500 monitor. For the general programmer, you can get by with less – a 17-inch LCD retails for less than $200. Sounds like a no-brainer, right?

The same logic can be applied to the purchase of an entire system. What is the productivity cost of having to wait for downloads and load times over the cost of a new system? Even if no new revenue is generated by the company directly as a result of the software or hardware purchase it can be worthwhile to invest in new equipment. Why hire someone and not provide them with the best tools possible to do their job? It’s kind of like putting a Mazda engine inside a Ford (wait a minute…)

  • improved satisifaction
  • reduced ‘switching’ time
  • employees more knowledgable with ‘current/cutting edge’ software

There was a time in the early industrial revolution when buying equipment and machinery was prohibitively expensive, and people could be trained to keep old hardware running for many years in order to maximize that equipment’s value to the company.

Today the reverse is true – computer hardware can be acquired at a fraction of a cost of the person needed to run it – and the training involved in having someone fill the shoes of a departed worker can be crippling to the bottom line of a business. Instead of trying to make machines last as long as possible it should be the priority of any manager to make the people last as long as possible. In a world where individual jobs are replaceable and just a stepping stone to “something better”, volumes are said by the simple act of someone staying in their role for a prolonged amount of time – both about the worker and about the quality of the employer they give their time for.

What I Learned from MUDs

Friday, August 1st, 2008

The first bit of code I ever worked on was ROM 2.4, a text-based MUD server written in C.  At the time I didn’t know the first thing about programming, but through trial and error I was able to feel my way around the source code and slowly learn how the language worked and how to make the program do what I wanted.  Some experienced programmers called me the “snippet king” because I used a lot of pre-written additions to expand m game, but I see it as part of the learning process.  If I were to work on a MUD again, I now have the knowledge to do all of the programming myself – but if it weren’t for my baby steps back then I may never have become a programmer at all.

Text-based gaming is all but unheard of now that games like World of Warcraft and Everquest have taken hold.  In my opinion this is a crime because the worlds created through words were so detailed and so interactive that replacing them with pretty graphics makes for a much shallower experience.  It used to be possible to make life-long friends and really share interested, now the genre has been opened up to the lowest common denominator and there is so much swearing and name-calling that many older, more mature players don’t even bother.

I learned a lot of skills from my days playing MUDs that have helped me in my professional life:

  • Programming (obviously)
  • How to interact with others online
  • How to type very fast
  • How to write with personality
  • How to be thick-skinned (when people think they are anonymous, they are quicker to criticize and personally attack you, especially when you’re involved in content creation)

Form Trumps Function

Wednesday, April 30th, 2008

One (sad?) truth I have learned through the past several years is this: Form Trumps Function, every time. You can write the most elegant code in the world, produce an application that meets requirements 100%, but if it isn’t pretty to look at, your time has been wasted.

In fact – you can show a client a beautiful shell of an application that has no functionality at all, and they will love it.  Show them the same application feature-complete but without the design, and they will not want to pay for it.

The bottom line is this – when writing code, be it for web or for the desktop, always have an eye for the ‘look’ of your product.  Even when a separate designer is involved, the programmer can take responsibility for the ‘feel’ of the application – how the buttons move around, tab order, this kind of thing.

I am considering spinning this blog off to a second one devoted to designing applications (both GUI and web).  The design element can’t be ignored, so hopefully getting programmers more involved in the process will improve the situation on all levels.