Monday, July 2, 2012

What is programming...

The non-programmers that I know usually do not have a particularly good idea of what programming is.

I know that none of the people that I have in my circle of people really know what I do for a living.  Most seem to think that I fix hardware.

To be clear, I am mostly going to talk about programming from a utility or business standpoint.  But even games follow the same principles (although it might not be as obvious).

Programming is a natural thing that people do all of the time - but usually, it is 'throw-away' coding.  They figure out how do perform a task, perform the task, and forget about the whole thing until (unless) they need to do it again.

Computer programming requires something more regimented.  We (you) are figuring out how to explain to a computer exactly how to perform a task.  Because computers are very good at doing exactly the same thing over and over again (but not good at filling in the blanks if you skip a step) it is important to include every necessary step.

Good computer programming would require making those steps simple.  Computers can follow complicated steps, but when you are trying to read your work in the future (or someone else is trying to read it) simple will be easier for you.  And a good practice would be to make sure that not only are your steps as simple as possible, but that you make them self describing.  Name variables so that the tell you what they hold.  Put in comments.  Include logging that makes your program tell you what it is doing as it is doing.

Great programming adds in speed and elegance.

There is no one way to add speed and elegance.  I think that mostly, they will come from practice at trying to be a good programmer.

I think that every program is made out of a small number of 'major' parts.

  • Data
  • Presentation/Input
  • Processing
The data is the information that your program has to work with.  Whether it is temperature and wind measurements for a weather modelling program - or the amount of money in your bank account along with your deposits and expenditures...data is the whole reason for writing a program.  It is what you want to keep track of and the building blocks that you need to solve a problem.

Presentation is how you show your data (and results) to your user.  Input is how you get the source data from them.  Ugly screens or complicated interfaces will make it more difficult for someone to use your program.  It may be the best at what it does, but if it is painful to use...no one will ever know that.

And processing is all of the work mixing the data together and applying various rules against it.  If you have the best data and the most pleasant, understandable presentation...It will not matter if you program does not do something useful (and correct) with it.

From the order that I listed them, you would probably infer that I think the data is the most important part of the puzzle.  And, you would be right.  If your data is wrong or you are keeping track of the wrong information - your system is never going to be useful.  So, the first step in any programming exercise should be to figure out what your data is.

But, whatever you come up with will probably be wrong.  With practice, you will get closer to being initially right (so keep practicing) but you will need to keep an open mind as to what needs to be kept track of.  And also, what your user will need back from you.  As you move through the process both sides of that equation will (hopefully) become clearer and clearer.  As changes make themselves obvious - adjust.

The next part of programming is figuring out how you will get that starting information from the user, how you will show them what they told you, and how you will give the results back to them after they have been processed.  You will also need to figure out how the processing actions are going to be started.  Will the user press a button on screen, set a timer, etc...?  A well designed user interface is one of the things that can make or break a program.

And finally, what processing needs to be done?  There needs to be a payoff for your user otherwise, they will not go through the bother of starting your program (never mind taking the time to enter all of their data into it!).  This is where the meat of programming is.  Someone has a problem that they want solved.  It is a problem that requires keeping track of a lot of information or performing difficult manipulation of information (or both).  Sometimes your user would be capable of doing that work themselves and sometimes they will not be.  You will need to make it 'cheaper' (in time, stress, accuracy) for them to use your program than to do the work themselves.

This is a little more than strictly 'programming'.  Working through all of these would encompass system analysis, system design, interface design, data processing, as well as the programming part.  If you have a team to work with and each person takes a piece - that might make it easier for each to become expert at the part they do.  But I would say that being able to see the big picture and all of the parts is what truly makes creating programs fulfilling.

Thoughts?

Thursday, August 12, 2010

Big snakes and programming...

I have started trying to learn Python again.

This time, I am using the book "Hello! Python" by Anthony Briggs.

I am only a few chapters in so far, but it is an easy read.  It is going fairly slowly for me, but that is because its audience is beginning programmers.  And, it seems like it would be great for new programmers (or hobbyists) getting started with Python.

The book is still in its 'early access' phase, so it is only available online as a PDF.  But, you can order it as a 'real' book too and get a copy in digital form to start on while you are waiting.

Did you miss me...

I had these grand plans for this blog and I think that those big plans kept me from keeping active here.

I thought that I needed to have something big and important to say before I said anything.

I am going to try to get over that.

Small things can be important too.

Monday, November 16, 2009

The little things mean the most...

There is a programming pattern that I had never seen before.

That is, there are multiple constructors of a Java class that share a 'base' block of code that needs to be called for each of them.

Well, I try to minimize opportunities for bad typing.  So, when I came across a situation like this - I created a method called base() that would be called by each of the constructors.  That way, the code would exist in one place and would be easier to keep clean and up to date.

Good plan right?

It worked, but today I was playing with the idea of making my big giant app send Twitter updates to let me know what was going on and notify me as errors occured.  The java library that I stumbled onto was twitter4j by Yusuke Yamamoto.

I wanted to make sure that if I tried to send a large (more than 140 character) tweet - it would be handled gracefully rather than getting truncated.  At first glance, they would have gotten truncated.  I'll have to check further to see if this is true.

But, my base() trick is not as clever as I thought.

There was a better way, that I never saw before today.  And that is to use the regular zero parameter constructor by calling it from each of the other constructors as this().  Clean and beautiful - thanks Yusuke.

To myself I say...

Duh.

Tuesday, November 10, 2009

Cookbooks and Recipes: Men, Women, and Programming...

Disclaimer: I think that everyone who chooses to be a programmer has to be (at least) a little bit crazy - whether male or female. But I think we are missing out by not having more female programmers - so if you are female and so inclined then I at least would welcome you. Also, I have a strange sense of humor.

So... Now that we've settled that...

I got to listen to Kirrily Robert speak at ApacheCon last week. She gave a keynote about women in open source and technology called 'Standing Out In the Crowd'. And it struck me that there are numerous books on programming that include the words 'cookbook' or 'recipe' in their titles.

Now, I love to cook - so I don't mean to imply that cooking is in any way a 'womanly' pursuit or task. But, there are many that think of it that way.

Anyway - one of the ideas that are presented as justification for the fact that there are few females in programming is that somehow the 'pink brain' is not suited to mathematics.

I will not even bother arguing whether or not this is true (Kirrily cited a study that determined that there was a slight difference). Regardless of any difference that may exist - it does not matter. I have been a programmer for over two decades and with the exception of a very small number of projects - there has been very very little math that was involved.

What is involved (as far as I am concerned) is understanding a problem and then teaching a computer to go through the steps to solve it.

So, how good a programmer you are is determined by:
  1. How well you can wrap your head around a problem.
  2. How well you can learn a particular language's syntax.
  3. How well you can break the solution of the problem into a sequence of steps.
  4. How well you can codify those steps in the language's syntax.
Most of the time, not much math.

Some languages may lend themselves to solving particular types of problems better or more 'elegantly'. But I have never heard of a language (human or computer) that is somehow easier to learn based on which gender you are.

Sometimes, boolean algebra can be used to make solutions 'prettier'. But most of the programmers that I have worked with never studied boolean algebra - male or female.

Hopefully, math will stop being used as justification for saying or thinking that 'women can't program'. And instead, the idea that programming is really teaching gains more mindshare.

Not every person who decides to be a programmer is cut out for it. There is a certain amount of insanity necessary to be good at it because you are effectively trying to teach a machine to solve a problem by describing the solution in a language that is not natural for you -or- the computer. And the computer is not going to go out of it's way to bridge that gap. That is all up to you!

There is nothing that I can see that makes males more suited to programming than females. And empathy (seeing a situation from the point of view of the other 'person') is often thought of as being a trait that is stronger in females. So, if there is a natural advantage held by anyone - it might be by women.

So, if you have an interest in foreign languages and in teaching completely empty-headed students who will force to you explain every single step in excruciating detail - then programming might be for you.

There may be a very good reason why there aren't more female programmers.

They are smarter than us.

Tuesday, November 3, 2009

Goin back to Cali...

I am in California.

This is the second time that I have been in this state.

The first time was over fifteen years ago.  And I was here to see how a software company was planning on translating their product from a character based program that ran from a command line in either DOS or _nix - to a windows program.

They were going to try to use a program to translate a BASIC language system to Visual Basic.  But the program required a person to make sure that the individual programs were written according to a set of programming standards.

They almost never were - so they ended up doing a substantial rewrite and forced those that had written customizations to write them all over again.

This time, I get to attend the 10th anniversary ApacheCon.

Over the past ten years, the Apache foundation has grown from a small group of people who forked the code from the NCSA web server - to an international group of programmers and users who develop and use a growing set of software projects (currently more than 60 and growing).

About three years ago, my day job gave me the opportunity to develop a substantial new system that would eventually replace a number of scattered information systems that spanned spreadsheets and flat file databases.  It would also integrate that information with the company's accounting system.

In trying to figure out the best platform for developing this new system I stumbled onto WebSphere community edition (WASCE) and through it - Apache Geronimo.

I was hooked.  Here was an environment to develop for that was scalable, standards based, open source, fast, ... everything I could hope for.

Through Geronimo - I found a number of other projects that are integrated by Geronimo.  And each of them was the same - open communities that seek feedback and encourage participation.

I do not know how many people are reading this.  Or how many of you are involved in software development.  But it is an amazing thing to find people spread out across the whole world who are passionate enough to give away their time and energy developing and/or supporting software.

Last time in California turned out to be a moderately interesting waste of time.

This time, nothing has really started yet - and I am already excited to get to be a part of something so bold and (at least in my experience) unique.

This is, in a word...

Awesome.

Wednesday, October 7, 2009

OSGi (or - late to the party again)...

Just when I thought that I might have been getting in on the beginning of 'the next big thing' - I find out that I am actually ten years (years?) late.

Recently the Apache foundation accepted a new podling into the Incubator called Aries.

If you are unfamiliar with the 'Incubator' and/or 'podlings' - take a look at this page on the Apache website:  http://incubator.apache.org/

Anyway, the Aries project seeks to develop the bridge between OSGi and Java EE.

I have come to really like the way that Java EE makes separating the front end development from back end processing.  And since OSGi seems to be the way that much of the Java world is going - I'm trying to get in on the ground floor with Aries.

But, the 'ground floor' is pretty high.  OSGi has been around for ten years now.  And so there is quite a lot of 'assumed knowledge' that goes along with it.  Also, the actual specifications for Java EE in OSGi are still being written and are not expected to be finished until the beginning of 2010.  Aries hopes to help in fleshing out those specs as well as providing an implementation of them.

Well, I should get back to reading the specs that have been written.  They are only 516 pages long (ack!).

So far.