Software Engineering

Posts related to the many elements that are Software Engineering. From planning, to design, to implementation, this has it all.

First Impressions of Rust

Today I finished my first program written in Rust 0.10.  As with my article on Dart earlier this weekend I’m going to rely on Wikipedia for short intro for what Rust is.

The goal of Rust is to be a good language for the creation of large client and server programs that run over the Internet.[13] This has led to a feature set with an emphasis on safety, control of memory layout and concurrency. Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable to C++ code that manually takes precautions comparable to what the Rust language mandates.[14]
Wikipedia

My first Rust program followed the same pattern that some of my other coding exercises have followed, that is implement an N-Queens puzzle solver.  While not terribly complicated, the puzzle does force an introduction to several important aspects of the language.  Since this was my first take on Rust, I am sure that my implementation isn’t great.

I found Rust to be an interesting language.  One of the more interesting opinions I developed about it was that it really prevents developers from doing something stupid.  That’s probably why it gets high marks for safe, concurrent code.  If I were to compare Rust to any other languages, I would say that it is syntactically similar to Scala and C++.  The strictness of the compiler does make learning the language a little more tedious than some other languages, but nothing that can’t be overcome.  I am probably a little biased on that point too since I’ve been writing a lot of Python lately.

On performance, I did noticed that it was about 60% faster than a architecturally similar python n-queens script I wrote.  I guess that’s not entirely unexpected from a compiled language.  I really want to figure out Rust’s threading capabilities.  That should greatly improve performance of the puzzle even more since it parallelizes well.

Rust has some serious potential and I predict as the language progresses, we will see more apps being written in it and more libraries available for it.  I for one will be continuing to tinker with finer details now that I have this program done.

Links:

Posted by Chad Dotson in Programming, 1 comment

First Impressions of Dart

Today I finished my first Dart tutorial.  For those that don’t know what Dart is, Wikipedia has a nice synopsis that I’ve included here.

Dart is an open-source Webprogramming language developed by Google. It was unveiled at the GOTO conference in Aarhus, October 10–12, 2011.[4] The goal of Dart is “ultimately to replace JavaScript as the lingua franca of web development on the open web platform”,[5] but Dart currently relies exclusively on its cross-compilation to JavaScript feature in order to run in mainstream browsers. Dart is intended to address issues with JavaScript that Google engineers felt could not be solved by evolving the language, while offering better performance.[5] Google works on Dart to help it build more complex, full-featured client-side Web applications.[6]

Dart is a class-based, single inheritance, object-oriented language with C-style syntax. It supports interfaces, abstract classes, reifiedgenerics, and optional typing. Static type annotations do not affect the runtime semantics of the code. Instead, the type annotations can provide documentation for tools like static checkers and dynamic run time checks.

Wikipedia

While the tutorial was simple and designd to be completed in about an hour, I found it a worthwhile and informative endeavor.  It was just enough to give an introduction to the language and syntax.  As the above snippet from Wikipedia states, Dart cross-compiles into JavaScript and should be familiar to people who know another C-style language.

I have a high degree of experience with object-oriented design, C++, and JavaScript and Dart has left me with a good first impression.  I believe an important aspect of Dart is that it could be used to bridge the gap between C-style languages and JavaScript for programmers who do not have a lot of JavaScript experience.  I do not believe that Dart will ultimately replace JavaScript, as Google hopes.  JavaScript, while it has shortcomings, is ultimately very powerful and flexible.  Dart’s ultimate utility will be something akin to CoffeeScript that is making it easier and less tedious to write JavaScript.  In the coming weeks I may delve further into Dart, though up next I will probably do a tutorial or two on Rust.

Links: Dart 1-hour tutorial

Posted by Chad Dotson in Programming, 1 comment

Presentation Is Everything

PRESENTATION IS EVERYTHING

There is something that learned over the past couple of years, presentation is everything. It is quite possibly the most important element in all we do.

Presentation from the aspect of leadership can mean the difference between shared vision and unengaged worker bee. Presentation from the aspect of a product ( in my case software product) means the difference between phenomenal success and utter failure of a product.

In short, no matter how good or revolutionary your product is, if it looks bad, it will fail. To have a physical product example, look no further than the current mobile phone market. Look at two products: one you like and one you hate. What are the specs of each one? Are they comparable or does one have an advantage over the other. Now, for arguments sake, lets say the more “cool” one has a better physical appearance and a more flashy user interface but the one that is less “cool” looking and has a plain user interface has better specs and capabilities, which one would you buy? I’m betting (and society proves) that the “cooler” one with the more flashy interface wins out more than the other device. I’ve got no facts in front of me to prove this directly, only experience and my own beliefs.

FIXING OUR SOFTWARE

So how do we fix our software? Well here are some design concepts to keep in mind.

  1. The API and/or the user interface for software must be intuitive.
  2. The software features must be discoverable. This means that users can learn to use the software by using the software. There is not a need for an involved manual to pick up the software and begin using it.
  3. The software must be easy to use. This is an ambiguous and loaded statement I know, but never-the-less it must be true. Just think about the software you are writing from the user’s perspective.

These are some of my most important concerns for a software product because if a user cannot easily pick up your software and start using it immediately, then you will have problems with adoption within your targeted user base. As with the mobile phone example above; if you have two pieces of software equivalent in terms of capabilities and specs, but one is presented a lot better and is more user friendly, which would you choose?

Going Forward

What we’ve learned here can be summed up in the two following statements. Software must be intuitive, discoverable, and easy to use. Also, presentation and appearance are quite possibly the most important part of software.

Posted by Chad Dotson in Doing Things Better, Featured, Key Concepts, Software Engineering, 0 comments

Programming Progress

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” – Bill Gates

I have that quote on my instant messenger. I found out Friday that someone had saw and used it. Its good that someone found it useful. It’s a very valid point to make that lines of code isn’t an accurate measure of programming progress nor complexity. As a place to start, people looking for better methods might like Feature-driven development with a meaningful estimating system like PERT, CPM, or other system.

Posted by Chad Dotson in Doing Things Better, Programming, 0 comments

DateTakenPhotoSorter.py – A python script for sorting photos

I decided this script was a necessity since I’ve been arranging my photos based on date taken since I bought my first Canon point and shoot.  After buying my Nikon 5000, I was disappointed to find the Nikon’s sync software did not break photos out into directories based on the date they were taken.  Yesterday, I finally had time to sit down and code it up.  This script should work on any platform and can work via either command line or via drag-and-drop.  Simply give it one or more directories using either of those methods and it will sort the photos in each directory based on the “Image DateTaken” Exif field.

Download Link: DateTakenPhotoSorter

SVN: http://cdotson-utilities.googlecode.com/svn/trunk/DateTakenPhotoSorter

Posted by Chad Dotson in Photography, Programming, 0 comments

MonoDevelop 2.0

I heard about this today.  I’m really impressed that they’ve brought it this far.  I’m going to have it install it on one of my virtualized linux installs and try it out.

The MonoDevelop team is proud to announce the release of MonoDevelop 2.0.

MonoDevelop is a GNOME IDE primarily designed for C# and other .NET languages. MonoDevelop enables developers to quickly write desktop and ASP.NET Web applications on Linux. MonoDevelop makes it easy for developers to port .NET applications created with Visual Studio to Linux and to maintain a single code base for all platforms.

via MonoDevelop 2.0 Released – MonoDevelop.

Posted by Chad Dotson in Programming, Technology, 0 comments