Author: grantbow

I’m fascinated to learn from the comments what other people have seen.

Best practices in computer programming, especially for devops types of positions, consistently involve Test Driven Development, pair programming and continuous integration. While quite a bit of research has been done on the topic, most people seem to agree that an agile approach to devops yields better quality code, perhaps at the short term expense of some time, especially in the beginning. New things take time to learn. However if you factor into the TCO the time required to update, adapt, operate, troubleshoot and otherwise change a system of this nature then huge gains can be consistently proven if cultures can adapt to the new way of doing things. Modern systems have smaller risks with regard to both requirements and implementation with less management and business overhead.

Looking at TDD, unit testing builds a set of tests just before coding, acting like a vice around the functionality provided by your code. You Now have the freedom to made more radical changes with quick feedback to respond to environmental changes. You can improve your code with fear that it will break. The quick feedback of unit tests run quite often alleviates any apprehension that a system will somehow break mysteriously and require extensive debugging. After a test environment has been setup, tests can be added to legacy code gradually, providing confidence and assurance that things are working as intended now and especially as changes are made and new tests are added.

The more experienced I’ve had with computer systems in different ways, the more I believe that the people involved dictate what an environment is like much more than any one or group of technologies.

You wouldn’t visit a doctor who did not keep current with medical journals. You would not hire a tax attorney who did not keep current with the tax laws and precedents. Why should programmers work for companies that do not keep both keep current and provide an environment where their employees have lower stress, are more productive and stay around longer?

For a moment, let’s look at the opposite perspective for a moment. There are often good reasons for the status quo, good reasons for doing things the way they have been done before. Tried and true computer programming idioms and their exceptions might be well understood by programmers that developed the systems. However newcomers asked to make changes are unable to rely on the experience accumulated in developing these systems initially. Newcomers also lack the experience accumulated working with a system under different conditions and during previous changes and updates. Of course using the same code the experienced folks don’t have to learn new ways of doing things and can more easily jump back in should something go wrong for any reason. New coders may also come and go, leaving behind a mess either accidentally or intentionally, so keeping things the same is safer.

We meet at Bobby G’s Pizzeria on the second and fourth Sundays of each month from Noon to 3PM in Berkeley near the Downtown Berkeley BART station. Bobby G’s is on University Ave near Shattuck Ave. We hope you join us, join the discussion on our email list and/or join us in #berkeleylug on freenode.net by following the tabs at the top.

Prentice Hall publishes two books I’ve been reading. Working Effectively With Legacy Code and Clean Code that both promote TDD. Please see my previous blog post on test driven design. Writing tests may slow you down at the beginning but helps you go faster later. It also forces you to think about all the business questions that go into your code up front. TDD creates a vice around your code so you know when something changes and has an unintended consequence.

I’ve been using shunit2 instead of BATS which I mentioned in my previous post to begin writing tests for some shell scripts.Has anyone else written similar tests for their code?

We meet at Bobby G’s Pizzeria on the second and fourth Sundays of each month from Noon to 3PM in Berkeley near the Downtown Berkeley BART station. Bobby G’s is on University Ave near Shattuck Ave. We hope you join us, join the discussion on our email list and/or join us in #berkeleylug on freenode.net by following the tabs at the top.

This is a problem I need help with. How hard can it be?

I want to interview people and record a podcast using open source software. Skype isn’t an option. Is jitsi the answer?

We meet at Bobby G’s Pizzeria on the second and fourth Sundays of each month from Noon to 3PM in Berkeley near the Downtown Berkeley BART station. Bobby G’s is on University Ave near Shattuck Ave. We hope you join us, join the discussion on our email list and/or join us in #berkeleylug on freenode.net by following the tabs at the top.

I was excited to earn 200 points on AskUbuntu.com this week. I have been making use of AskUbuntu and other sites in the StackExchange network like stackoverflow, the Wikipedia of coding Q&A. I was then automatically awarded 100 points on it and all the other websites in the network. I was looking forward and have now earned the 500 points necessary to see and vote on user-submitted moderator flags, review queues.

What have been your experiences using their sites?

We meet at Bobby G’s Pizzeria on the second and fourth Sundays of each month from Noon to 3PM in Berkeley near the Downtown Berkeley BART station. Bobby G’s is on University Ave near Shattuck Ave. We hope you join us, join the discussion on our email list and/or join us in #berkeleylug on freenode.net by following the tabs at the top.

A new AI movie (warning, spoilers are in the link) Ex Machina is being released this weekend. Who’s going to see it?

We meet at Bobby G’s Pizzeria on the second and fourth Sundays of each month from Noon to 3PM in Berkeley near the Downtown Berkeley BART station. Bobby G’s is on University Ave near Shattuck Ave. We hope you join us, join the discussion on our email list and/or join us in #berkeleylug on freenode.net by following the tabs at the top.

At some point you may want to know about why something is stuck, whether it’s your own code or someone else’s. Print statements, command lines and logging are fine when you need them but only if you are writing your own code. More is possible. The higher level strace and lower level gdb are good tools to use when something is stuck. While dtrace or SystemTap are certainly amazing and powerful, reaching inside a live kernel, few people want or need that much power.

What are your experiences using these tools?

We meet at Bobby G’s Pizzeria on the second and fourth Sundays of each month from Noon to 3PM in Berkeley near the Downtown Berkeley BART station. Bobby G’s is on University Ave near Shattuck Ave. We hope you join us, join the discussion on our email list and/or join us in #berkeleylug on freenode.net by following the tabs at the top.

There are certain things sysadmins rely on a lot. If they break it’s really not good. For me, the grep tool is one of them, so I was surprised to find inconsistent results. Based on otherwise good advice I was trying to use grep -i '[p]rocess' to look for running processes. When it didn’t work correctly I discovered related bugs 28981 (includes a good test case) and 36567 so that for us in our environment grep fails when:

• trying to match upper case data (lower case matched ok)
• using dash i for case insensitive
• using square brackets as above
• LANG was set with UTF8

Evidently this has been a problem for a while. Though fixed upstream the fix hasn’t made it’s way to all production Linux environments, making the use of this common trick a bit risky in production.

What other problems have you encountered that you choose to code around?

We meet at Bobby G’s Pizzeria on the second and fourth Sundays of each month from Noon to 3PM in Berkeley near the Downtown Berkeley BART station. Bobby G’s is on University Ave near Shattuck Ave. We hope you join us, join the discussion on our email list and/or join us in #berkeleylug on freenode.net by following the tabs at the top.