Today’s Progress

Today I created a video for my students. If you happen across this, let me know what you think. Keep in mind that I am fully aware of the fact that I still have some things to work out, but to be honest I’m in a hurry. I’m creating content for five courses in three weeks. I promise it’ll get better.

Update: I’m really not doing this to brag on my mad skillz; I really want to find out if the videos are 1) viewable from any browser and 2) viewable from tablet devices.

Resources for Web Design

In the next few weeks and what is hoped for a long time after, I’ll be diving in to serious Web design projects.  I’m looking for the best resources to make designing sites easier and result in high-quality environments.

Instead of keeping them in a document for myself, I’ll do my best to add to this list when I find a great article or other resource.  That way we all share.  Some of these links are to other lists themselves. Here goes:

Getting it Done

Linux and NTFS

I’ve been through this before and had to look it up again today.  This post is simply a reminder for the inevitable next time I can’t remember it.

I typically install CentOS on a box or in a VM with minimal packages so I can bring in only what I need.  I did just such a thing yesterday to have a machine I can use to rsync data here and there, and do some remote administration.

One primary purpose was to take my backup drives from my house and sync to a share on a storage array at work.  This serves as my off-site backup consolidation.

Instead of tying up a Windows machine and using their experimental SyncToy (which has been performing worse and worse lately), I chose to use a Linux-powered data management machine.  It will eventually synchronize the local backups at home to the storage array at work, but there’s only so much time…

Anyway, my little 1TB external drives are formatted in NTFS, and we all know that’s not a native Linux filesystem.  We’ll have to install a library.  We had to do the same thing to mount a Windows network share (CIFS), a library which was readily available in the default YUM repository – no problem.

The utility needed for NTFS is not, however.  It’s found in the Extra Packages for Enterprise Linux (EPEL) repository, available from the Fedora project.  This is a very long way of saying that you need to enable the EPEL repo by installing the proper RPM (currently available here for EL6 x86_64), and then install the ntfs-3g NTFS userspace library package with YUM.

Keep in mind that there are a lot of other cool things in EPEL, but at present you just need to remember this one.

>= 1 Mile per Day

I’ve tried to commit to crazy things, like reading all of my unread books in a short time and cycling every morning.  However, I just got some motivation.

The Beer Runner has been running at least one mile and drinking at least one beer every day for 846 days now.  Yesterday he woke up after having been discovered by the influenza virus and apparently had a time with it.

Given the condition he described, he still ran that mile and drank a beer.  I should be ashamed of myself having my own commitments interrupted by late nights with sick kids, traveling, studying, and the timeless cases of the “I just don’t feel like it” syndrome.

Famous last words of a commitment: Starting tomorrow…

Starting tomorrow I will run at least one mile every day.  I’m not too crazy about the idea of having to drink a beer every day too (it gets expensive), but the daily minimum-mile I can and should do without fail.

Every morning presents the opportunity.  If I get up late, I run in the afternoon.  It’s only a mile.  If it’s raining, storming, or just too late in the day, I have a treadmill and won’t be ashamed to use it.  While I have every excuse not to run, there is a way around or through that excuse.

I’d like to say I’ll keep this blog updated with my runs and experiences, but I’m not going that far.  A mile a day is enough for now.  Follow @42flows on Twitter for the Runtastic posts made when I finish each run.

And wish me luck.

Upgrading from OS X 10.5 after it’s Too Late

 

We have needed to upgrade the two Macs in our house (our 2008-ish aluminum iMac and Beth’s 13″ white MacBook) to the current OS X for a long time.  Weeks ago I discovered it was too late to upgrade online – upgrading to 10.8 is done through the Mac App Store, which isn’t available in 10.5.  Also, finding an incremental upgrade to a version that includes the Mac App Store is impossible.

In Atlanta last weekend I decided to stop at the Apple Store to inquire about upgrading with a disc rather than finding more ways online.  Even the Apple Store couldn’t help, as they didn’t have discs anymore – especially with the age of our OS (we’re now three releases behind).  The associate told us that the only way to upgrade from 10.5 now is to call Apple.  Wow.  When you’re behind, you really are behind.

So that’s what we did.  Last night Beth wanted to put a ringtone on her iPhone (with iOS6) from iTunes, and couldn’t.  Apparently our phones were too advanced for our computers.  That was the last straw – it was time to pull the trigger.  She called the Apple Store at 1-800-MY-APPLE (1-800-692-7753) and spoke to someone who somehow understood exactly what we needed.  We bought a family pack of OS X 10.6 (Snow Leopard) for about $30, and after upgrading to that we can upgrade to 10.8 (Mountain Lion) from the Mac App Store.  How convenient.

We’ll have to pay for both upgrades, but a total of $60 to upgrade two computers two times is still far less expensive than upgrading a single Windows machine from Windows Vista to Windows 7.

It’s SO FLUFFY!!!

I had this idea the other day while watching Despicable Me to find or make a ringtone of Agnes’ line in the movie when she scores the big stuffed unicorn and screams “It’s SO FLUFFY!!”

It was a fantastic idea.  If you’d like to download the .m4r file, it’s here.  You should be able to put it in your iTunes library (or perhaps directly to your phone).  I’m not sure – I just grabbed the mp3, threw it into GarageBand, and exported the tone to iTunes.  Enjoy!

Install GNOME Desktop through YUM

When you install something like CentOS with 512MB RAM, the graphical installer doesn’t launch due to the memory restriction and you are relegated to a text-based install.  It’s a colorful CUI (chewy; command-line user interface) and the installer doesn’t let you choose packages (at least in CentOS 6).  You get a very small “minimal” install by default, and when you’re up and running you can install your needed/favorite packages with yum.  The minimal install doesn’t give you a desktop environment, and I keep having to look up which packages to install to get GNOME on a Red Hat-based system that was installed without a GUI.  I have to do this about twice a year and I can never remember which packages are needed.  Jeffrey B. Murphy has a post that explains it simply, and I’ll repeat the simple yum command here:

yum groupinstall basic-desktop desktop-platform x11 fonts

There. Perhaps someone will find this or Jeffrey’s post helpful. I’ll update this if needed later.

A lot of forum posts you’ll find mention a “GNOME Desktop Environment” group, but that doesn’t seem to work at present.

Elementary Software Design

There is a process to be followed when designing or redesigning software systems, whether that process is the same for every system or not.  There are just some things that need to happen that will help solidify the product and get some kind of stability in the software and in the customer’s confidence.  This is a general overview, if for no other purpose than to remind myself of it.

1. You must have a problem.  If not, what the hell are you doing?  Software tells computers to solve problems in most cases.  In all others, the problem is that the programmer doesn’t know something and is moving through a project to learn an aspect of development.  Those learning projects are the hardest to get through sometimes.  Anyway, either you or your customer has a problem that can be solved with computers, and that’s why you’re here.

2. Gather requirements.  This should always be the next step, and it should always be very early – before you pick a platform, language, development team, or flavor of Jolt, gather the requirements from the customer and start hacking at the root of the problem.  This is the most important step, because it is from here you will begin to draft your agreement with the customer about the scope of the project.  Requirements gathering should be done as diligently as possible to ensure you and your team know the scope or constraints of the solution you’re developing.

3. The agreement.  This is where you hammer out exactly what problem you’ll solve and every aspect of the solution.  This statement of scope will define the limits of the product and the customer should be told that they cannot add anything once an agreement is reached.  Imagine getting to the end of a nine-month project and the customer changes the requirements…  It will waste time and money, and WAY more than you might think at first.  You’ll never really know what it’s like to have an insatiable desire to strangle someone until you have a customer trying to chisel something else into the project during testing.  Make sure everything is in the design to begin with, and work hard until it’s all agreed upon.  It’s much cheaper to work something in at the beginning than to wedge it in at the end.  Just ask Microsoft.

4. The Design.  Once the requirements and scope have been determined and agreed upon, it’s time to begin the specification for the software system.  This includes a functional design specification and a software design specification.  The two are closely related, but still distinct.  A functional design specification is a document describing what functions the system performs at a high level.  Since you’re building the software from the ground up, a system that performs these functions likely doesn’t exist.  If it did, we might buy that one instead of building this one.  So – given its uniqueness, we need to define its functions and general workflow.  A software design specification takes those functions defined in the functional spec and describes them in a way the code monkeys can understand.  The software design specification takes into account the limitations and nuances of programming languages and how computers work and applies that to the problem at hand to perform the function necessary in each part of the system.  This is the nitty-gritty spec that should describe everything down to the last detail so that when it’s handed over to a programming team, there will be no questions.

5.  Code.  But there will always be questions, so be ready.  During the implementation phase (the part where code is written and actually run on a computer), if the system is large enough there will be many iterations and backs-and-forths about minute details ranging from data types to interface colors.  Again, most of the details should be in the software design specification but, well, we’re human.  It always happens.  Only when the machines start writing perfect code can we relax about this phase.

6.  Test.  Often the most painful phase of a software project is the testing phase.  If it’s not painful, you’re not doing it right.  In my opinion, most of the time testing teams are needed, not just a single software testing engineer.  You have to throw absolutely everything you have at the code to see how bulletproof it is.  Testing tools, load generators, keyboard monkeys, children, everything.  Also, continual testing is necessary for ongoing maintenance to make sure newly-discovered vulnerabilities are being plugged and tested against in each iteration of deployment.  In short, leave no stone un-turned and never let a place get dusty.  Be very diligent at all times.  Software testers are not temps.

7. Document.  Every large team has turnover, no matter what the rate is.  People quit, die, get offers from their dream company, have mental breakdowns, etc.  In these cases where you’ve got a new person replacing a project veteran, documentation is essential to reducing wasted time.  First, the functional and software design specs should be up-to-date (and also interesting enough not to put the reader to sleep) and ready for anyone to review.  Each developer team member should also keep a work log of some sort to keep track of those small daily decisions he or she makes during the coding phase; the next guy may not know why you did what you did.

In conclusion, I can’t say that these perspectives on the development process are always necessary with every software development project, but some aspect of these steps will come in to play in everything that isn’t a two-line script.  Whether anything is documented during the conception or planning stages is irrelevant; those things happen whether you write them down or not.  Each project has a beginning, a development, and (it is hoped) a use afterwards in the real world.

No matter what development methodology is used, design, testing, and documentation are all of equal importance.  If you’re managing your software project by the seat of your pants, get a grip on things and start documenting.  Stop lying to yourself about that timeline and conjure up some real figures.

I’ll end with some books I recommend:

Joel Spolsky, Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity

Steve McConnell, Rapid Development: Taming Wild Software Schedules
and Code Complete: A Practical Handbook of Software Construction, Second Edition

Andrew Hunt and David Thomas, The Pragmatic Programmer: From Journeyman to Master