I’m still alive. I took a break, and ended up with a huge number of issues with my computer. That just made me take another break to avoid solving them.

While most of the procrastination is over now, it’ll still take me a while to get back into things.  I’ve got a couple of projects which I’m forced to put on the back-burner, and a couple which I’ve never mentioned which I’ll be working on – and they may or may not be announced.

I’m not sure what stuff I’ve even got going, so for now just assume that everything’s being delayed by a huge amount.

I did get a hold of the Unity Linux gang to let them know what’s up, and I’ll hopefully be returning to light duty sometime mid-December.

Btw, I’m using TinyME-alpha3 right now, and it seems to work just fine.  My tastes differ quite a bit, so I’m really just using the underlying skeleton.. so it’s not like I’m using the actual distro.

So this isn’t much of a teaser for things to come, but at least it’s something.  =p

Yes, I actually had to look this one up. Apparently nobody thinks DVD menus and using your mouse for them) would be a sensible default.

mplayer -mouse-movements dvdnav://

And no, this doesn’t work with gmplayer. That would be crazy. =/

So at some point you migrate from little scraps of paper to sheets of paper.

Then you migrate to notes in your computer.

Then you migrate to a documentation system.

Then you migrate back to notes in your computer.

Then you migrate to one big note.

Then you categorize your notes.

Then you review and prioritize your notes.

All the while, your notes have been gathering strength, preparing to assault your free time.

You open the flood gates .. and .. nothing happens.  The very notion of a list is intimidating, and actually “doing” anything is based on inspiration.  Priorities have shifted around so much over the years that looking at the list just gives a lot of “yeah, that ought to get done one of these days” instead of the burning-hot passion there used to be.

David Smid has updated rpmfind.unity-linux.org to include the Granular Linux packages.

Note that Granular Linux has not put out a new stable release based on Unity Linux, since Unity Linux itself has not made a release yet.  This means that the rpmfind listing doesn’t apply to the present stable Granular Linux ISO.  However, a preview alpha demonstrating a KDE-only desktop environment has been released yesterday.  It is meant for Unity Linux testers, and most definitely NOT for everyday users to play with.

Here is his notice:

KDE 4.3 is ready and available in Granular repository. I’ll shortly
commit the source changes to the Unity SVN repo as well. But those of
you wanting to try out the shiny new KDE release without getting into
installation hassles of any kind, I have prepared a KDE-only Unity
ISO, based on 0.99 Alpha 2 release.

This ISO contains KDE 4.3 as the only DE; no Openbox. Although I
didn’t get enough time to make sure it contains a clean KDE
environment, as far as I’ve tested, it works just fine. It contains
all the KDE packages as required by “task-kde4-minimal”. Granular repo/
channel is also added to the smart channel list, with a priority
higher than Unity’s. But you can change it any time. It also contains
Firefox and Amarok, and can play multimedia as well. :)

I hope you have a nice experience with it. Let me know how it goes.

Get it here (460 MB):
http://www.granularproject.org/content/unity/unity0.99_kde.iso

Extra info-
username: root
password: root

username: guest
password: guest

MD5SUM: b7a3899b5975c36c1ab71dc24e243f2e

Drop by the mailing list if you have feedback: http://groups.google.com/group/ul-developers

The Granular Linux head Anurag Bhandari continues to work with our internal Unity Linux alphas so that he can release Granular Linux as soon as Unity Linux goes stable.  I do know that TinyME is also doing the same.

Keep in mind that a bunch of us are using Unity Linux as our primary operating environment.  While Anurag has chosen to release an alpha publicly, which was quite a surprise to me, the Unity Linux core has not publicly available yet because some significant effort needs to be made to make it compatible with more hardware and to stabilize our choice and configuration of software.  For example, there has been some recent discussion on changing the way applications are organized in the repository and menu.

Also, David stopped indexing PCLinuxOS packages, since Unity Linux has been fully-independent of PCLinuxOS for some time now and Mandriva is the primary source for inspiration.

One of the things that’s been a real killer for me using most wikis has been the syntax.  None of them get it right.

MediaWiki has been bearable, and over time I’ve grown used to it.  The problem is that nobody agrees on a remotely similar syntax.  There were some early efforts to create a generally agreed-upon syntax, and it did fairly well.. but it’s still not used everywhere.

I’m not just talking about wikis, but about markup languages in general.  Even something like Ruby’s rDoc decided on its own syntax.

And they’re all wrong.  Seriously, who thinks  that __this is italicized__?

I’ve even seen and participated in some discussions on better syntax, and programmers keep saying that it’s hard to create certain kinds of syntaxes.  They’re wrong.  After some dabbling I was able to create a markup language myself.  Easily.

_underlined_
-strikethrough-
/emphasis/
*bold*
**big**
_ - / underlined strikethrough italics /-_

Everyone can understand that syntax.

Oh, and I could easily zip off and create \italics\ <i> which is separate from /emphasis/ <em>

Plain URL automatic-linking was trivial too:

http://example.com
=>
http://example.com

Simple syntax like this is really only for the shorthand for everyday English. Sure I could create ^superscript^, and maybe =subscript= and `pre` and whatever else comes to mind.. those become less and less obvious and more about personal preference. `backticks` are used in shell scripting, so that one’s easy to remember. Superscript is obvious.. subscript not so much.  I figure if someone needs to do something fancy, they could just use proper HTML.  I’ve maintained the habit of using HTML wherever possible, because it makes it much easier to move the source to another wiki without having to translate everything.

And yes, I do realise that I ought to be using CSS instead of the old HTML v2 stuff.  I’ll get around to that.

Oh, and about wiki linking. I implemented an automatic linking. Screw all the [[some title|whatever]] nonsense. If you need to do that, you’re doing it wrong. I just have the engine check the list of files, then check for appropriate phrases and build links intelligently.

So if I have some-example.html, then

some example text
=>
some example text

That code is a huge maul right now, but it’ll turn into a smaller hammer soon enough if I manage to do things like link only one occurrence per section – so between <h1> and some other header there is only one unique link to a file, and in the next section another link can be made.

Syntax should get the hell out of the way, and the computer should do as much of the clumsy footwork as possible.

I can think of still-smarter things I could do.

the last word in this sentence is a linkhttp://example.com
=>
the last word in this sentence is a link

That’s a bit messy, but I could imagine something cleaner..

the last word in this sentence is a link

sentence continues.
=>
the last word in this sentence is a link sentence continues.

I’m even tempted in doing a standard and a print version. The standard version would have inline links, but the print version would remove all linking and instead have endnote references, with a nice list of links at the end. Heck, I could automatically tinyurl all those links too.

Source

This is a sentence with a link

http://example.com

Regular:

This is a sentence with a link

Print:

This is a sentence with a link[1]

[1] http://example.com

So all in all, this is an excellent learning project. I find file and string processing to be the very best for my goofing around. Ruby is very good at string processing, and while its file processing is slow, it’s also very simple to work with.  Oh, and I still hate regular expressions.

This little syntax “engine” is still being hacked on, but it’ll get released eventually.  I won’t really chain it to any other project like my compiled website, so it can be used wherever it needs to be used – toss it a variable and it’ll return a conversion.  Or just use whatever bits of it you like.  Stay tuned.

So as to keep my comment around..

Any media which attempts to mimic the real world will at best maintain a niche interest because of the art or nostalgic memories of the piece.

For example, old movies who had early special effects were astounding at the time, and are laughable now. They’re only interesting for the nostalgia of old people who saw it when they were growing up, or to historians of film or effects.

The same is true for games. Any game which tries too hard will end up falling down flat later in time, when their early art form is totally obsoleted.

However, games which do not attempt to be cutting-edge and realistic have amazing staying power. Think nethack, online MUDs, most early Sierra games and any other game which has a focus on comedy and thinking.

This same thinking somehow doesn’t seem to apply to old world art forms for all people. There is some sort of attachment to painting and other art forms where they hold their own even in comparison to photography. It seems that the act and the material is more important to people than the actual image. I think it’s just a cultural thing for us to respect painting, but beside that a lot of painting doesn’t attempt for realism in the first place.

But regarding games.. there are a number of very active projects devoted to re-creating old games or emulating the original on other platforms. Arcade games, early computer games (Atari, c64, Amiga, etc), old x86 DOS games, and more.

There are now a couple of projects which will work on directly supporting much more of those old games at the operating system level, both based on Unity Linux – http://unity-linux.org

For my part, I’ll be working on Oldschool Linux, which is more focused on the oldschool demo, music and art scenes.

The other person’s project will be more directly focused on games and emulation. I went looking for its name and the author, but I wasn’t able to find it. It’ll resurface once the project launches.

I strongly appreciate a single-application single-tasking environment, because it forces you into a totally different mindset from the flurry of activity and noise one always has on an everyday “multitasking” computing environment these days.  But since most of my day is spent completely surrounded by multiple applications all vying for my attention, I’ve come to expect to be able to swap my attention around whenever I want.

But there are situations and applications which explicitly deny multitasking.

Seriously.

It pisses me off so much to have basic functionality taken away from me.  Maybe there really are underlying reasons, technical or otherwise, for an application to not multitask “properly” (for me), but it still pisses me off to no end.

A classic example is when a popup window unnecessarily stays “on top”, obscuring that and other applications.  Sometimes the popup window is stuck “on top”, and it seems to explicitly ignore my unsetting that flag.

Some actual examples:

• Firefox 3.5.2
  • Won’t multitask with bookmarks in the sidebar.. page loading etc.
  • Won’t let you control-t or control-w when a plugin has focus.
• Claws Mail 3.7.1
  • Prevents you from doing quite a lot of things when it’s checking mail.
  • Has the perma-popup when the preference screen is shown.
    • Bug 1963 - Preferences Templates Information Window Focus loss

Maybe I’ll keep posting other applications as they annoy me.. this issue really rubs me the wrong way.

As I promised in another post today, here is some basic code to get you started on using Ruby’s Test::Unit.

I also figured out how to do the wordpress.com syntax highlighting.  Yay.

testall.rb

$LOAD_PATH.unshift("#{File.dirname(__FILE__)}/../lib") if __FILE__ == $0

puts "Checking for test cases:"
Dir['tc_*.rb'].each do |testcase|
  puts "\t#{testcase}"
  require testcase
end
puts " "

tc_example.rb

# http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/files/test/unit/ui/console/testrunner_rb.html (not a useful website)
# TestRunner is used to ensure that code can be run after the tests are run, without resorting to wrapping this entire script within another script.
require 'test/unit/ui/console/testrunner'

# http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/
require 'test/unit'

class TC_EXAMPLE < Test::Unit::TestCase
  # Execute this before every test case.
  def setup
    # Do nothing.
  end
  # Execute this after every test case.
  def teardown
    # Do nothing.
  end

  # Tests
  # Stuff with "test" at the start of their name will be run automatically.
  # Other things without "test" can be manually launched with the setup method.
  # Note that we need to have one test case.  With zero test cases, ruby bombs out.  I don't understand why.  It's stupid.
  def test_empty
    # Empty.
  end

  def test_file_exists_pass
    # I can summon this to manually abort the test if I wanted to.
    # abort_test!
    # This tests for itself, which ought to pass.
    assert(test(?e,__FILE__),"** ERROR:  The file is missing")
  end # test_file_exists
  def test_file_exists_fail
    assert(test(?e,"filename.ext"),"** ERROR:  The file is missing")
  end # test_file_exists

  # Tests (and only tests) can use "abort_test!" to stop their own execution.  Other tests continue as normal.
  # This stuff has to go down here.  (I'm not sure why)
  def abort_test!
    throw 'abort_test!'
  end
  def self.abortable m
    m, m2 = "#{ m }", "__#{ m }__"
    alias_method m2, m
    define_method(m){|*a| catch('abort_test!'){ send(m2,*a) } }
  end
  instance_methods.each{|m| abortable m if m =~ %r/^test/}

end # TC_EXAMPLE < Test::Unit::TestCase

# Somehow, all the tests are run _after_ these types of code are run!
# A global variable (an array)
# at_exit { code }
# END { code } -- either if I use the end block before, or after require 'test/unit'

puts "== beginning the tests"
Test::Unit::UI::Console::TestRunner.run(TC_EXAMPLE)
puts "== finished the tests"

Lately I’ve been reviewing my skills and interests, and sketching out what I’m interested in learning and accomplishing.

Malcolm Gladwell was on The Hour, and he talked about his “10,000-Hour Rule” from his book Outliers.

It’s been a little bit since that episode aired, and I realized that I’ve actually put in my 10,000 hours on a couple of topics now.

It’s been more than ten years since I became obsessed with software testing. But I ought to say that with different terms.. this version of “testing” is better-called “reviewing”. Throughout those ten years I’ve kept progressively clearer and lengthier notes, and these days I’m very tempted to dive into very in-depth reviews.

I’ve had a sort of intuitive expertise.  But it’s not a functional competency, like an trade skill that’s learned on site, it’s more like a guitarist who “just figured it out”.  That kind of guitarist may be outstanding in many ways, but they often can’t even read sheet music and have no working knowledge of the fundamentals.

With this “10,000 hours” in mind, when I think about wanting something, my perspective completely changes.  Instead of “it could have been done better” or “it’ll be so hard for me to do that myself”, with a kind of distant daydreaming mindset, I find myself thinking more along the lines of “I’ve put in the hours, I know what I’m doing, I could get this done myself”.

But I do know that I’m at best “a natural” and that while I’ve put in the hours to develop portable “soft skills” and a sort of intuition, I’m lacking those fundamentals.  So while I have talent for usability and documentation, and I’m learning to program, I lack the underlying organizational and other true “development” skills:  Specs, planning, prioritizing, testing, etc.

I know how to get those missing fundamentals.  I’ve already started some of the research on the core topics I’ll need to absorb, and I’m seriously thinking of getting some paired programming going.  I took a serious look through The RubyMentor Project, and I was appalled that there’s been no improvement in all this time.  They’re still using that piece of shit wiki.  Nobody has spearheaded the project, and it shows.

At the moment, I have several significant projects all on the go at the same time.  It’s not just Unity Linux that’s high on my list.. there are a number of programming and personal projects which are just as important to me.  Some of those projects have been patiently waiting for me for years now.  I really need to get them all done.

But creating a “doing it right” project is something that I am compelled to do.  I learn by documenting.  I only learn by documenting.  This naturally leads to tutorials, but now I’m going to expand it and have it lead to behaviours, tools, methods, styles and anything else I can think of.  It’s a reasonable leap to go from that to a full online course, including some sort of real-world Meetup.com or virtual paired-programming.

I don’t understand how an online mentor is useful.  There is a huge community out there, and it’s responsive and helpful.  One of the first and most important skills one can learn for programming is to define one’s questions well, and know where and how to look for answers.  Once that skill is even mediocre, asking for random help from a mentor is just being lazy.

The value in having another person available isn’t with getting answers.  It’s getting wisdom.

First, I’ve had the pleasure of sitting down and chatting with a number of very capable programmers.  They’ve shared all kinds of stories and tools and techniques.  This kind of knowledge isn’t gained in asking them questions, it’s gained through general discussion.  One doesn’t need a mentor to have that discussion, one just needs a friend.

Second is paired programming.  At first it seems like a waste of both people’s time.. sitting down working on the same thing, tripping on eachother’s code, questioning and countermanding eachother’’s work.. getting derailed by conversation.  But it’s that same conversation which is so valuable.  One person is always teaching the other.  One person is always learning from the other.  One codes, the other searches for answers.  It’s probably the best time I could ever imagine spending on my code.  For this too, one doesn’t need a mentor.

So while I can’t imagine a value in a mentor, I can imagine great value in a similarly-skilled partner for paired programming.  A mentor is someone who is head and shoulders above the mentee, but that’s often a Bad thing.  It’s Bad because too often the mentee is merely absorbing the skills of the mentee.  When two equally-skilled people are put together, they are each able to explore without being bogged down by the perceived expertise of the others.  The pair can learn and argue and teach oneanother.  A pair has a flow of knowledge going both ways, where a mentor-mentee relationship too often flows one way.

While it’s very likely that a mentor will relay their best skills, they will often have favourite tools, methods, etc.  With a pair working together, they will each develop their own favourites, and they will each help the other understand their reasoning.  Between the two people, the tools, methods etc. will be better than the benevolent bias of a mentor.  I argue this because the tools, methods etc. are changing over time, and the mentor is always a little out of date.

But all the wisdom the mentor has cannot be omitted from the pair’s learning experience.  This is where a good “best practices” site comes in.

http://blog.majesticseacreature.com/archives/2009.03/rbp_blog.html

Gregory is on the right track.  I hope that works out, because it’s a resource that will be essential for people like me.. permanently learning and never quite sure we’re learning the right stuff.

I think that there’s a place for making more “newbie friendly” information available.  As I said earlier, it’ll be an inevitability for me to write down my thoughts and experiences and create a concise tutorial which others can follow.  It’s not for right now, but it’ll happen so long as I’m interested in programming.

I act in cycles.  I am inspired by and I work on something new, and that inspiration shifts around.  I also have a tendancy to drop and pick up projects in cycles.  In the past I’ve dropped ideas for long enough for all effort to become meaningless given enough time, but these days I’ve been careful to cycle back to earlier ideas to scrape off the cruft and re-launch the project.

When I re-launch a project, I often find myself bringing significant maturity to the table.  I have new ideas and techniques, and I take a kind of sick pleasure in redoing much of my previous work.  This isn’t just a programming thing.. it applies to anything that I’ve been working on.

So when I cycled back to programming as an overall topic, I decided to research languages and techniques again.  I went through a bunch of languages, most of which I still have a significant amount of notes from previous reviews.  I even sat down and started hacking around with Python.  But the more time I spent on any of that, the more I missed Ruby.

Ruby is crap.  It’s garbage collection, threads and IO suck.  It’s slow.  It has no compiling.  It’s crappy in so many ways, but because of it’s syntax and community.. it’s fun.

I can’t help it.  I look through language after language after language.. and I miss Ruby.  So I decided to look into Ruby some more.  I only have basic competence with it, but I’ve still managed to create some impressive (to me) stuff with it.

While I know that the syntax and community are extraordinarily important for a programming language, I also know that underlying philosophies, techniques and tools are also important.  So – as I have many times in the past – I went looking into all of the foundation of what I know and how I work.

I had done some playing with unit testing in the past, but somehow I ended up straying from that previous knowledge and work by creating my own automated testing systems.  I don’t really know how or why I forgot my earlier knowledge either.  So when I realized this recently, I found some old code and stripped it to create a simple example for myself.  I’ll make another blog post with that, to help out the other Ruby Test::Unity newbies.  Actually, automatically linking my notes system with blog posting is something I’ll eventually get into.. when I build my monstrosity of a CMS/Wiki/Weblog.  One day.

At any rate, when researching better testing and testing tools, I came across Behaviour-Driven Development (BDD).  I’ve had exposure to Extreme Programming, Agile Development and similar stuff, so BDD isn’t particularly new to me.  But I did bump into Cucumber, and I started to get more interested.

I figure that if I step way back, and get into some sort of spec-writing like that, then I can help direct my attention and improve my programming.  This kind of work is also programming language-agnostic, so I could much more easily switch to whatever language I was goofing around with at the time.

But one of the biggest reasons for my wanting to get into it is to help with the loomingly-large “compiled website” project which I was working on.  I say “was” because I managed to drop that project and skip a number of opportunities to get back into it.  Nice specifications would break the project down, making the whole thing much less intimidating to set down and later pick back up.

Specs could also help me better understand my priorities .. to distinguish “must have” features from mere wishes.

At any rate, I’ll do some more research on all of this, and hopefully I’ll remember to blog something about them.

I’ll end this with my quick interpretation of What are the Qualities of a Good Test?

Technical:

1. Isolated from the outside world
   • Doesn’t talk to the database, communicate across the network, touch the file system or do special things to the environment
   1. It is written gray-box, i.e. it reads as if it were black-box, but sometimes takes advantage of white-box knowledge. (Typically a critical factor in avoiding combinatoric issues.)
2. Isolated from other tests
   • Unaffected by the presence, absence, or results of other tests. No dependencies. Self-contained.
   1. Order Independent and Isolated – it should be possible to run the tests in whatever order the test runner chooses.
   2. be able to run at the same time as other unit tests, even concurrently with itself
   3. It does not test the object inside the running app, but instead in a purpose-built testing application.
3. Repeatable in every aspect
   1. Test your boundary conditions and Always keep your tests passing at 100%.

Social / Convenience:

1. Simplifies design and improves productivity. Improvements in code quality and a reduction in bugs are an important side effect.
2. Intention-revealing – the best unit tests make it clear to the reader how an objects API is intended to be used.
3. Easy to Setup
   1. Short, typically under a dozen lines of code.
   2. It invokes only a tiny portion of the code, most usually a single branch of a single function.
   3. Quick and easy to write
   4. It is generally written before the code-change it is meant to test.
   5. Maintainable
4. Fast to run/complete
   • As above, it’s short and invokes a tiny portion of the code.
5. Unique (providing confidence not provided by other tests/uncorrelated with other tests)
6. Automated
7. Readable
8. Trustworthy
   1. Coded to the same standard as shipping code, i.e. the team’s best current understanding of coding excellence.
9. Promotes code commits: In combination with all other microtests of an app, it serves as a ‘gateway-to-commit’. That is, a developer is encouraged to commit anytime all microtests run green, and discouraged (strongly, even nastily) to commit otherwise.

I have no idea what that means:

• It avoids most or all usage of ‘awkward’ collaborators via a variety of slip-and-fake techniques.