Older blog entries for sjanes71 (starting at number 105)

Testing Wisdom

I’ve run into a problem where the DOM of Chrome and Firefox return different HTML results where they rearrange the attributes of elements when jQuery.html stringifys them. Don’t fight it outright with writing a bunch of code to check the existence of attribute values, etc.

Just write a “satisfies” assertion and get on with your day:

function(x) {
return (x === '<div a="1" b="2"></div>' 
     || x === '<div b="2" a="1"></div>'

If the other browsers you’re testing in also give you grief, it is still probably easier (and faster) to just add to the satisfy’s clause than try to do a more sophisticated match.

Syndicated 2012-06-01 19:38:19 from sj4̄nz

Restarting Cinnamon in Linux Mint

Talk about a need-to-know feature. Sometimes, Cinnamon gets confused. Logging in and logging out is super disruptive to productivity, so being able to restart Cinnamon without blowing away everything you have open is a nice option to have—if you’re aware of it. It’s buried in the “Troubleshoot” menu, which I never thought to look into before. Silly me.  If you really want to get geeky, the “Looking Glass” console lets you inspect all kinds of X11 weirdness.

Syndicated 2012-05-22 04:02:37 from sj4̄nz

Eight Aspects of Software Development

Eight Aspects of Software Development

April 2008 (Unpublished; Revised 2012 and Published)

I’ve been doing software development in one way or another for many years and have explored lots of different bits of philosophy. Here is a course of practical software development. These are the things you know, improve and practice.

  1. Reading and Writing — The process of writing well is the same skill-set as programming well—neither will improve without practice and neither will improve without reading quality examples. Its a matter of terminology and results. In both cases, you need a goal [what kind of thing you're making], a plan [how you're going to make it], and patterns [the types of things you do to make it]. Doodling on a notepad in writing would be like programming little snippets or prototypes for future reference or idea capture. If you were writing a short story, your programming may be the implementation of a function or algorithm. Writing a report or case study could be compared to a library in programming. Writing a novel may be compared to writing an application. Writing an office suite or enterprise system could be a multi-volume encyclopedia. Words, sentences and paragraphs: variables, statements and functions. You can only improve your writing by reading other people’s words and code. I stress other people’s because reading your own work doesn’t work—in your mind, you know what your intent was. When it comes from another mind, you’re forced to concentrate on the communication without access to their thoughts.

    Writing is a process of creating a repeatable form of communication for others. Programming is a process of creating a repeatable form of process for computers. If you’re not closely reading either words or code by others, you’re not improving your writing.

  2. Programming fundamentals — Knowing how to program is all about knowing the semantics commonly used for programming. Its not the syntax, its what you say. If you are thinking about getting into programming, you will need if-then, while-loops, for-loops, functions, methods and some understanding of how information is represented.

    The fundamentals of programming are distilled into the packaging of algorithms composed of decisions, loops and arithmetic.

  3. Language commitment — Choose your specializations and know the language weaknesses. I liked PHP because of its ubiquity everywhere except Windows. If the servers I worked on were based on Windows [IF... I've never seen a reliable Windows system, so why make them a server?], I would likely have to accept ASP/VisualBasic as the language to use in that environment. If I need more "research" style programming, I’ll consider Scheme or Arc. Today, I spend much more time deep in JavaScript or CoffeeScript—because that’s where most of the computers are.

    Don’t be a language zealout—but consider alternatives to exercise your understanding of programming fundamentals.

  4. Design Patterns, Algorithms and Data fundamentals — Design patterns are ways of composing algorithms together for reuse. Knowing how to model data efficiently, or how to trade memory for speed and vice versa are a must. Start with a bit, add bits and meaning to store numbers, use numbers to encode symbols, and so on. Knowing what algorithms exist can help you avoid repeating work (think of a catalog of algorithms like being a free-for-all patent office, someone else has done the hard work and given it to the world and the patents are all expired.)

    If you haven’t searched for any algorithms, you’re reinventing the wheel 99% of the time.

  5. Test-driven development discipline — "Trust, but verify", a signature phrase of Ronald Reagan was appropriate because of the Russian phrase: Доверяй, но проверяй. (I just like copying and pasting crazy letters… but that’s another story.) Test-driven development makes your life so much easier–you write your tests to check the operation of your program, and then you automate the execution of those tests so that you only need to worry about them when they fail. Run them often, write them continuously. If you are not writing tests, you are not programming for reliability. This is the hardest aspect to stay reliable with—because writing tests isn’t exciting to most people. You really have to treat them as the programmers TODO list:

    If you didn’t write a test, it isn’t important enough to be done.

  6. Event-driven, Aspect-driven and Concurrent-distributed programming — Event driven programming is a big departure from functional programming, and aspect-driven programming is kind of like a fusion of functional programming and event-driven programming. Aspect-oriented programming isn’t taught much yet in schools, but I have found it to be a disturbingly easy way to defer the binding of "what, when and how you do it" to the run-time systems of aspect-oriented systems. Think of it like event-driving programming on more steroids than Major League Baseball. It does bring in a new set of vocabulary terms that will initially confuse you like "advice" and "pointcut", but in the end they’ll help you talk to other programmers about what you’re doing. You don’t have to have a compiler to support it, like object-oriented programming in C, you can do it on your own as well. Concurrent-distributed programming forces you to think about systems as they work together instead of in singular nodes–these are the exciting bits of programming because you can to begin thinking of your systems as being cells cooperating in an organism that comes to life. There are a lot of issues to manage in distributed systems, you’ll spend a lot of time formalizing the interactions. Some would throw the "Service Oriented Architecture" buzzword about for this kind of programming.

    Event-driven programming is valuable for software that must interact with the real-world. Functional programming ideal for making software reliable and predictable, and concurrent-distributed necessary for orchestrating collections of computers. My gut feeling is still out on aspect-oriented programming as a useful method of organizing code.

  7. Source control discipline — This is where you learn discipline and earn a big assist from the computer: you’re going to let the computer track the changes to your source code. My personal choice for source control is now Linus Torvald’s GIT because of its supreme awesomeness. The borderline between backup systems and source control is more and more blurry–in other words, use your source control as your backup system, I do. Then I back that up as well.

    If isn’t worth tracking your changes, how will you be able to find "where things went wrong" in the future?

  8. Tool commitment — Which editor are you using? Have you learned the 20% feature set of what you’ll use it for 80% of the time? Really well? Do it. The better you know your tools, the easier your work becomes. The less you switch between tools, the less time you’ll waste re-learning how to do things. Learn when to use the mouse and when to use the keyboard. Once a year, if you have time, evaluate all of your tools to see if they "need sharpening"– that could mean upgrading or replacing. I’m an vim convert from emacs after I realized that I wanted hardcore simplicity for text editing. Typing "c4w" becomes "change the next four words" and I didn’t have to use the mouse to select the text! Get polished with your editor and source editing starts to become a stream of consciousness or nearly automatic act. I’m not a big fan of IDE frameworks like Aptana because the tool starts to interfere with the work: especially when updates rearrange your workspace, not to mention, the time lost when the workspace spontaneously explodes from "the replacement of a small screwdriver inside." If you must use a complicated environment like Aptana, back it up with the tool you use in #7: source control–it’s not just for your source code anymore.

    Since vim, I’ve found that I need better navigation of the "files" instead of the text and I’ve switched to Sublime Text. I miss some of the keyboard-ness, but the swiss-army chainsaw ST provides makes up for it.

Syndicated 2012-05-20 14:38:00 from sj4̄nz

An idiom for nesting anonymous functions in CoffeeScript

I have some code that is very brief, but called with a timeout. It’s tiresome to name two functions just so you can call them indirectly. Anonymous functions are quite brief in CoffeeScript:

    () ->
        somethingThatCalls( () -> some other work here )
    , 1000)

You probably don’t want to go too many levels here, but its convenient for short bits of code.

Syndicated 2012-04-28 14:30:40 from sj4̄nz

“The fundamental rule of political analysis from the point of psychology is, follow the sacredness, and around it is a ring of motivated ignorance.”―Jonathan Haidt

Syndicated 2012-04-25 05:00:46 from sj4̄nz

CoffeeLint Configuration for Tab-Indentation CoffeeScript Authors

I’m falling into “use a tab” camp for source-formatting and counting tabs as indentation. If you want to configure your source editor to make those tabs appear as 2, 3, 4 or even 8 spaces wide, go ahead. For me, I think of them as logical mark-up for your “intent” of “identation.”  Any tab to me means one level of indentation.

Here’s a CoffeeLint.json configuration for that kind of work with CoffeeScript:

 "no_tabs" : {
 "level" : "ignore"
"no_trailing_whitespace" : {
 "level" : "error"
"max_line_length" : {
 "value": 80,
 "level" : "error"
"camel_case_classes" : {
 "level" : "error"
"indentation" : {
 "value" : 1,
 "level" : "error"
"no_implicit_braces" : {
 "level" : "ignore"
"no_trailing_semicolons" : {
 "level" : "error"
"no_plusplus" : {
 "level" : "ignore"
"no_throwing_strings" : {
 "level" : "error"
"cyclomatic_complexity" : {
 "value" : 11,
 "level" : "ignore"
"line_endings" : {
 "value" : "unix",
 "level" : "ignore"
"no_implicit_parens" : {
 "level" : "ignore"

Yes, I realize that this JSON file itself is not tab-indented.

Syndicated 2012-04-17 01:55:12 from sj4̄nz

Storm Aftermath

Love the sky after a storm. It’s so much cleaner, like it has been swept of pollution.

Syndicated 2012-04-16 13:57:47 from sj4̄nz

Note to Self: Dude, You Don’t Need FLAC; gPodder WTF?

Sure, disk space is cheap. But backing up gigabytes of data is a royal drag. But I’m finding that if the MP3 is of high-enough quality (by this I’m thinking whatever lame --preset extreme excretes out in hot-and-steamy MP3 bits) I don’t mind. Additionally, I’m tired of fighting with devices that don’t understand OggVorbis or FLAC—like the in-dash media player in my car. That’s just not a battle worth fighting. MP3 has won, another case of a technically inferior standard achieving supremacy via overwhelming network-effects. So, it’s time to sweep the drive and downcode FLAC to MP3.

How to do this? Well, flac -dc FILENAME.flac | lame --preset extreme - -o FILENAME.mp3 is the recipe of the moment.  That’s one itch scratched, the next one is more complicated.

gPodder ← ಠ_ಠ

gPodder has really gotten on my bad-side of recently with broken releases. I tried going to Miro which didn’t work well anymore (like it used too) and even iTunes for a bit. No happy. Not at all. I’m a victim of my want of simple-UNIX-like-tools-that-do-just-one-thing-well. When it comes to agents that perform work for you on their own, they’re awful with syndicated media downloads. I’m this far (||) away from considering using cron and wget and bailing wire to download the media. Somehow. Take the “Back to Work” podcast for example:

 # remove the old copy of the RSS file 
rm back2work
 # grab the feed
wget http://feeds.feedburner.com/back2work
# gank out the last three episodes and 
# download if not seen before. 
grep enclosure back2work |head -3| \
cut -d '"' -f 2|xargs wget -nc

At least for now, that’s a version-0 idea of what I want done. Just the files, downloaded. For now, there’s no setup or configuration and I haven’t decided where this is going to happen on the computer yet.

Syndicated 2012-04-09 04:07:39 from sj4̄nz

“Open Ended”

Lush hip-hop from Algorhythms.

Syndicated 2012-04-04 13:41:39 from sj4̄nz

96 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!