While posterous will not allow me to add JS to blackout my site, I figured I'd use this space to throw up some information for those unaware of these two bills.
Please, if there is one thing you do today. Educate yourself on SOPA and PIPA. It is extremely important.
I've seen questions for this topic come up repeatedly so I figured I'd throw something down to refer people to. :)
If you're interested in NodeJS, and I'm betting that you are, then you'll be wanting to make a project. There area few things you can do. Many, not all, people in the NodeJS community use Git and Github for source control and hosting respectively. You'll do fine hunting around there for things people have made on Github. Alternatively, the NPM repository hosts stable versions of each module and provides some conveniences for installation.
At the start you may be tempted to just something like:
npm install module
I'd recommend against this. While it will work in a pinch. But, a better approach would be to use the package.json file. At first it seems strange to do so, but it becomes natural very quickly. With this approach you get the benefit of having a file you can check in. This means that you can throw it in your versioning system and once done, type:
npm install .
This will install your current project and all of it's dependencies. It makes it really nice when moving around machines. I usually work on two machines and then deploy on another. Having a file that makes installation easier is really nice. The file itself would looks something similar to this:
Note that you do not need to put your project in NPM. We're talking about managing your dependencies and other project information. However, one caveat is that this file needs to be proper JSON.
If you're interested in more, take a look by typing:
If you're looking for a coding tutorial you're in the wrong place, but if you'd actually like to learnNodeJS then stick around. This will cover the basics so that you can understand why things work the way they do. A base understanding is what you should start with. So, lets get into it shall we?
A Brief History - SSJS in the Making
Over a few recent years a handful of projects has tried to bring Javascript to the world of serverside programming: RingoJS, Axiom Stack (which I was involved with), Jaxer, and NodeJS among others. There are also a few javascript virtual machines out there: Rhino, V8, and Spidermonkey. This abundance of tools has allowed for those who really love Javascript to dive head first into server side development.
The project that has gotten the most attention for bringing SSJS is NodeJS. The attention it has received is largely due to two things: the way with which you write Javascript and the speed at which you can do so. You see, NodeJS set out to work through events and callbacks. What this means is that your traditional concepts around procedural programming were just thrown out the window. And, while functional programming has been around for some time, this is a wonderful blend of functional and evented development. There are arguments for and against this asynchronous approach, but I'm not interested in discussing that here. The point is to get you understanding it so that you can form your own opinions. So I'll explain why this works the way it does.
A Look at the Internals - The Event Loop
Events and callbacks are used because the core of node is an event loop. This means that you have a loop processing all of your code. If your code is procedural, step-wait-step-wait and so on, then you will eventually take up the entire event loop with your code and nothing else will be able to be processed. This would normally be fine, but most applications are complex that require some database interaction or writing to files. Additionally, you may need to send data across a network. This is where things get a little hairy. When you block the event loop you stop other code from executing and thus waste CPU cycles. The traditional example with node is this: if you make a database call then you have to block until you get a response from that database. This means that you cannot do anything else until that initial call has returned. This is known as blocking and will halt the event loop until it has finished.
var db = new DB(); var rows = db.getAllRows(); console.log(rows.length);
But, imagine this. You create a function that would take the result of your database call. Then you pass that function to your database call such that when the result set is returned, your function is fired off.
var db = new DB(); db.getAllRows(function(rows) { console.log(rows.length); });
I'm affraid that this alone is not enough to keep the event loop uncloged. There are two things to note. The first is that the db library you're using needs to be using events. And the second thing is that you can still make enough calls that you reach the system limits for your event loop and clog it, but in most cases this is either bad design or a good problem that you solve with more hardware.
Evented Libraries
Libraries don't event themselves. The developers need to be cognisant of that approach when creating the library. For node this can be in either C/C++ land or in JS land. Either way the approach works using the notion of events. For instance, lets say that I have a database library. In this library I make a request for all the rows in the db using the connection. This could take some time so I want to make sure I'm not blocking other execution and thus take a callback as the parameter. In the getAllRows api I set my code up such that when the result returns from the database itself your callback is fired with the response from the server.
function getAllRows(cb) { conn.on('results', cb); conn.getRows(0, conn.length); }
Although this is obviously a contrived example, you can see that what I've done is used an api such that when the results event happens, we fire the callback. Then, we make a call to the conn, db connection, object to get rows 0 - the size of the rowset. Although this isn't the most powerful example, it shows the essentials of an evented architecture. We just hang onto the callback in memory allowing the event loop to continue on with it's other tasks until we get a response from the database call, which is when we make our move. I've stated this point about 5 times by now I'm sure, but I hope it's really clear. This approach is asynchronous. That's 6. :)
How Does That Connection Become Asynchronous
If you look, there is an implicit assumption in the code above, that assumption is that conn itself is asynchronous. That works for my example, but it doesn't really explain anything. So, how does the connection become asynchronous? This comes back to node.
In node, we have something called an EventEmitter (refer to the link for the API). This is the backbone of eventing in node. The EventEmitter is a module whose backbone is libeio. This library provides the functionality needed to make your code asynchronous in NodeJS. The EventEmitter as a module provides you with publish and subscribe features so that you can make any code you write use events. So, the connection module would be required to use an EventEmitter in order to provide that asynchronous functionality.
A simple event emitter might look something like this.
Setting NodeJS Apart
What sets node apart from the competition is that there wasn't a set of libraries pre-built using other design paradigms. So, people have built a massive collection of libraries from the ground up to give you your chance at embracing the power within node. Hopefully by now you realize that you can do some awesome things using NodeJS. Armed with your new understanding here are a few links to get you started on codifying it.
Recently I added another slice to my list of servers but whenever I add slices on Slicehost with Ubuntu, they come with the locale problem. You might recognize it. The following shows up in almost ever source compile you do (frustration mounts):
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_CTYPE = "en_US.UTF-8", LANG = "en_US.UTF-8" are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C"). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory
Then, after reading the error you see that it doesn't even have en_US installed! *GRAH* Well, there is a simple solution. In my case I use en_US, but if you use something different then make sure you specify it.
cd /usr/share/locales
sudo ./install-language-pack en_US
sudo dpkg-reconfigure locales
This should fix the problem. To see what your system is set to use, you can do the following: locale
This AM I was attempting to update my existing version of Choqok and received an error. I thought I'd share since it did take a couple of minutes to find a solution for fixing. Dependencies:
I'm running Kubuntu Karmic, that's the KDE Ubuntu 9.10
The concepts will likely work elsewhere, but not within the nice packages provided in aptitude. The Problem
~/Code/choqok/build$ cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..
-- Found Qt-Version 4.5.2 (using /usr/bin/qmake)
-- Found X11: /usr/lib/libX11.so
-- Phonon includes NOT found!
CMake Error at /usr/share/kde4/apps/cmake/modules/FindPhonon.cmake:63 (message):
Phonon library or includes NOT found! Call Stack (most recent call first): /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:559 (find_package)
/usr/share/cmake-2.6/Modules/FindKDE4.cmake:81 (FIND_PACKAGE) CMakeLists.txt:3 (find_package)
-- Configuring incomplete, errors occurred!
Short Fix Use aptitude
~/Code/choqok/build$ sudo aptitude reinstall libqt4-phonon-dev
Reading package lists...
Done Building dependency tree Reading state information...
Done Reading extended state information Initializing package states...
Done Writing extended state information...
Done The following packages will be REINSTALLED: libqt4-phonon-dev 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 0B/57.7kB of archives. After unpacking 3,441kB will be freed. Do you want to continue? [Y/n/?] y
Writing extended state information...
Done (Reading database ...
264392 files and directories currently installed.) Processing triggers for man-db ...
Processing triggers for desktop-file-utils ...
Processing triggers for hicolor-icon-theme ...
(Reading database ...
264183 files and directories currently installed.) Preparing to replace libqt4-phonon-dev 4.5.3really4.5.2-0ubuntu1 (using .../libqt4-phonon-dev_4.5.3really4.5.2-0ubuntu1_i386.deb) ...
Unpacking replacement libqt4-phonon-dev ...
Setting up libqt4-phonon-dev (4.5.3really4.5.2-0ubuntu1) ...
Reading package lists...
Done Building dependency tree Reading state information...
Done Reading extended state information Initializing package states...
Done Writing extended state information...
Done
Long Fix Use apt-get
~/Code/choqok/build$ sudo apt-get remove libqt4-phonon-dev
Reading package lists...
Done Building dependency tree Reading state information...
Done The following packages will be REMOVED: kdelibs5-dev libphonon-dev libqt4-phonon-dev 0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded. After this operation, 13.6MB disk space will be freed. Do you want to continue [Y/n]? y
(Reading database ... 264392 files and directories currently installed.)
Removing kdelibs5-dev ...
Removing libphonon-dev ...
Removing libqt4-phonon-dev ...
Processing triggers for man-db ...
Now, reinstall the libraries that were uninstalled.
~/Code/choqok/build$ sudo apt-get install kdelibs5-dev libphonon-dev libqt4-phonon-dev
Reading package lists...
Done Building dependency tree Reading state information...
Done The following NEW packages will be installed: kdelibs5-dev libphonon-dev libqt4-phonon-dev 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/1,229kB of archives. After this operation, 13.6MB of additional disk space will be used. Selecting previously deselected package libqt4-phonon-dev. (Reading database ...
262408 files and directories currently installed.)
Unpacking libqt4-phonon-dev (from .../libqt4-phonon-dev_4.5.3really4.5.2-0ubuntu1_i386.deb) ...
Selecting previously deselected package kdelibs5-dev. Unpacking kdelibs5-dev (from .../kdelibs5-dev_4%3a4.3.2-0ubuntu7.2_i386.deb) ...
Selecting previously deselected package libphonon-dev. Unpacking libphonon-dev (from .../libphonon-dev_4%3a4.3.1-4ubuntu1_i386.deb) ...
Processing triggers for man-db ...
Setting up libqt4-phonon-dev (4.5.3really4.5.2-0ubuntu1) ...
Setting up kdelibs5-dev (4:4.3.2-0ubuntu7.2) ...
Setting up libphonon-dev (4:4.3.1-4ubuntu1) ...
Fin
The basic idea here was to reinstall the libqt4-phonon-dev library. This made it so that the include files were back in place and I could compile source code. Now, you should be able to continue compiling your phonon based source. In this case, as stated above, I was compiling Choqok. But, I doubt this issue is relegated solely to Choqok compilations. I just haven't yet had the opportunity to compile other KDE4 based apps on Karmic Kubuntu.
I'm ideating a method proposition to add enterprise grade value which will synergize your verticals.
*cringe* Hold on a second...I need to go wash off the dirty. In all of what I typed above, I didn't actually tell you _anything_. But, what you expect now is some thing that should make your things work well together. Why don't we just say that? Because people expect exact answers and the above sounds more like an exact answer! Keep in mind that most places wont do anything nearly as drastic as what I posted above.
Where To Begin?
Buzz words suck. Often times these words start as a way to differentiate products and/or services. While grande, buzz words tend to lose their meaning when _everything_ and/or _everyone_ uses them. When people adopt them on a large scale you're not actually saying anything. Most people can get the gist of what you're attempt to say because most people have a brain that works reasonably well, at the very least better than this weasel. However, you lose credibility when you start throwing those kinds of words around.
I've been, for a while now, trying to figure out why they are so popular. I'm not sure where it started. The main reasons for using them, that I can think of, are differentiation and filler.
Differentiation
The attempt to be different. This works out reasonably well when you're the first person/company to say that you are an "enterprise" solution. But, when every competitor uses the term, SURPRISE, you're no longer different. Or are you? What about the feature you can create a pony out of thin air? I'd say that likely differentiates you, wouldn't you? Stick to the features and to your capabilities. Those should be what differentiates you.
Filler
If you find yourself with a lack of descriptors then use the ones you can think of. When you "innovate" in the market, what are you really doing? People thirst for information so give it to them. You don't need to ramble on, but providing some detail is a great teaser. The movie industry uses teasers to pique your interest. You should do the same. Additionally, using buzz words doesn't make you sound any more intelligent. In fact, it often does the opposite because you aren't providing substance.
More Proof
If you need more proof that buzz words are everywhere and how irritating they can be. Sit at your next "all hands" type of meeting. Listen to the specific words being used. You'll notice that a lot of these phrases aren't really telling you much. It's almost like eating at McDonald's, you might get something that resembles a message, but really all your getting is an ill feeling in your stomach.
Try playing games like buzz word bingo. Another that I've played is to come up with a list of words and assign points to those words. Each person picks a word they think will provide the most points. Give each person a word to tally and then collect the tallies at the end. Multiply the tallies for the word by it's value and those are the total points. Once you have the totals you send them out. The prizes are your choice, I tend to prefer a free lunch, but it at least makes the 1-2 hour snore fest more exciting. The point is that you'll find out just how many buzz words and phrases are used to try and pitch you information and direction.
Where To Go From Here
Well, I'm certain I've used buzz words in the past. With so many floating around, it's bound to happen. Fret not, you can stop using them and gain back your credibility. Make a conscious effort to stop using them and give the terms meaning again. Also, you'll be generating more intelligent conversation. This, to me, seems like a positive.
Suggestions
You may be able to get a clearer picture of exactly what I'm talking about with some examples. So, here are some off the top of my head.
Enterprise - We can handle a lot of [users|documents|<insert noun>]. When you say this you'll need some statistics. So have them ready.
Web 2.0 - Our web application is primarily built using Javascript, AJAX, and some aesthetically please designs. We are also standards compliant.
Synergy - Our product works well with <insert other technology>. Or, this will allow <X> to work well with <Y>.
Best of breed - We've used <X> technology. This gives us the ability to do <Y>.
Leaders in - Hmm... No you aren't. Just accept it now and get over this phrase. KTHXBI.
Authenticity
One thing I touched on above was authenticity. When you stop using gibberish in your messages you gain credibility. People start to listen to your messages because they are gaining something from it. If you are interested in some ways to approach this take a look at Personality Not Included. I read this some time ago and really liked much of what Rohit had to say.
Go Forth
Go now and conquer! Take out those editors, rewrite those presentations, press releases and websites. Get the word out that you wont put up with buzz words anymore. And, if someone tries to push you into it, you can always threaten them.
At Axiom Software we're working on the next release of SEOversite. It's been exciting. This is basically a tutorial on debugging the Apache HTTPd side of things (keep in mind that this is as much an informational thing for you as it is a reminder for me. I assume that I'm going to have to re-read this at some point).
Background
In production, we've been using Apache on Ubuntu Server. This has worked out well seeing as aptitude rocks pretty hard. But, we run into some issues doing debugging and profiling. It's easier to have the code all within one place, so for development purposes we're pulling the source so that we can specify the configuration and compiler options for Apache.
Debugging
What other tool do you use to debug C code than the GDB? With any language you need a way to be able to properly debug your code and usually print statements just don't get it done. So, why stop at the ability to print out from the code when you can actually step into your functions, print out variables, and see back traces. With normal C applications you can simply just load the binaries into GDB:
# gdb <binary>
This doesn't quite work in our setup though. We are in the situation where we need to debug modules, not just Apache. And, to really be able to step into the code we need to compile it appropriately. When we're dealing with setting up our module for debugging we need to make sure we pass in the -g flag. The -g flag just makes it so that your code can be debugged with gdb.
So, we have our module which we'll call seoversite.c. We're looking to debug so our build looks something like this:
~/seoversite/# /opt/apache/bin/apxs -ci -Wc,-g seoversite.c
This turns on debugging within the binary which means that we are letting GDB process the source of our file. With apxs, the -Wc, flag allows you to pass compiler flags along for when your code is actually built.
We then have a really simple startup for GDB.
/opt/apache/# gdb bin/httpd
As soon as this fires we get a prompt that lets us specify what we want to do. Today I was debugging a simple method that processes a URL so I'll go through some of that. When we start up gdb we're presented with a prompt. This is where we need to enter some input.
(gdb) b get_fullurl
Function "get_fullurl" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (get_fullurl) pending.
Because our module is shared, gdb doesn't find the method signatures right away. That's ok. We'll wait till they load on the request. Basically, the above puts a breakpoint on the method call get_fullurl. Thus, any code paths that use get_fullurl will halt activity until processed in gdb. So, we start the server.
(gdb) run -X
Starting program: /opt/apache/bin/httpd -X
[Thread debugging using libthread_db enabled]
[New Thread 0x7fce2930d760 (LWP 14174)]
warning: Temporarily disabling breakpoints for unloaded shared library "/opt/apache/modules/seoversite.so"
[Switching to Thread 0x7fce2930d760 (LWP 14174)]
The command we typed was "run -X" meaning, start the binary with these command line options. -X is the debugging flag for Apache. So, we're telling it to start Apache HTTPd in debug mode. This is what we want. It tells you that it'd loading a shared library and is going to disable the breakpoints while it loads. Afterward it enables the breakpoints you've defined. At this point, because our code is dependent on a request, we should make one. I hit a virtual host url that is setup to use our module and immediately see that our method is hit.
Breakpoint 1, get_fullurl (ctx=0x19d4908, use_base=0, args=1) at seoversite.c:330
330 if (use_base) {
This isn't entirely useful information. I know where my method starts. However, we aren't limited to just this information. Let's say that I want to see the back trace of method calls that got me to this method.
(gdb) bt
#0 get_fullurl (ctx=0x19d4908, use_base=0, args=1) at seoversite.c:330
#1 0x00007fce2402299a in filtering (f=0x19cba78, bb=0x19d0298) at seoversite.c:1739
#2 0x000000000044f446 in ap_pass_brigade ()
#3 0x000000000047b2ed in ap_proxy_http_process_response ()
#4 0x000000000047bad0 in proxy_http_handler ()
#5 0x000000000046af37 in proxy_run_scheme_handler ()
#6 0x0000000000467524 in proxy_handler ()
#7 0x0000000000441450 in ap_run_handler ()
#8 0x0000000000441ce9 in ap_invoke_handler ()
#9 0x000000000048823c in ap_process_request ()
#10 0x00000000004851f0 in ap_process_http_connection ()
#11 0x000000000044ae72 in ap_run_process_connection ()
#12 0x000000000044b2f9 in ap_process_connection ()
#13 0x00000000004ac48b in child_main ()
#14 0x00000000004ac56e in make_child ()
#15 0x00000000004acb03 in ap_mpm_run ()
#16 0x000000000042857c in main ()
This is now getting useful. Not only is this nice for debugging purposes, it's really nice for inspecting call traces of modules you've never used before. Inspecting the actual behavior will provide you a much better clarity of the source code. In our case, this confirmed my assumption of the calls that lead up to getting to get_fullurl.
Now I know how we got to my method, but I need to see where it's failing. Ideally I have the source up in Emacs and can look at line numbers while debugging. What I don't get with this however is the ability to go one line at a time and inspect the values and types of variables. GDB provides this capability.
(gdb) n
334 if (ctx->f->r->parsed_uri.query != NULL && args) {
As with most debugging software, this allows me to step through code, line by line, to see what the execution does. Obviously, this is a useful thing. But, to enhance it we get the ability to inspect variables.
(gdb) n
334 if (ctx->f->r->parsed_uri.query != NULL && args) {
(gdb) p args
$2 = 1
(gdb) p ctx->f->r->parsed_uri.query
$3 = 0x0
And, to make sure you have the appropriate context for what you are dealing with, you can print out a handful of lines to accompany your inspection.
(gdb) l
327 char* baseuri;
328 char* fullurl;
329
330 if (use_base) {
331 baseuri = get_baseuri(ctx->f->r);
332 } else {
333 if (ctx->f->r->parsed_uri.query != NULL && args) {
Ultimately this has made things easier. And, there is no longer the "ok, add a new print line in here, recompile, run, check logs, rinse and repeat" type of process. It really simplifies my life when I have to hack on C code and I know it helped one of our other guys track down some memory based issues. The only downside here is that there is no longer any sword fighting.
Homework
If you watch the following video with Trent Reznor, it's about 40 minutes long, you'll likely understand the rest of this post. But, for the TL;DL crowd, the interview had a lot of undertones to it that I really thought needed to be elaborated on. Not only do they pertain to what he's doing within the music industry; what he discusses has to do with, at the very least, the tech industry. I see it as a fundamental shift in the way business is being conducted. At any rate, take a glance, and there will be more after the video.
ThoughtsFirst- Trent Reznor is the f*ing man.
Second- Trent Reznor is the f*ing man.
Third- there is new information coming out lately about how we're in a time of mergers and acquisitions (M&A). M&A is a way to grow your company in size (employment), in revenue and, if you did your homework correctly, in profit. Ultimately the point of the larger companies is to make themselves money. They need to sustain the business styles they have grown into. Younger companies tend to be far less concerned about the profit engine as they are a bout their idea. Pay attention here. If you listened to what Trent said about record labels and artists then this should sound familiar. However, his thoughts don't just apply to the recording industry.
Small businesses tend to be focused on producing some idea that changes the world, makes it a better place to live in, or makes my cheese burger taste even that much better. They are _not_ focused on whether the special sauce will be cheaper if they use Angus vs norm. In fact, a lot of smaller companies will make a deliberate decision to go for quality. They know it will cost more, but often that deliberate decision is an important differentiator in the market.
However, the businesses doing M&A tend to be focused on things that generate profit. They need to feed the meat grinder and produce dollars. After all, they have investors to satisfy. But, and this is where Trend hits the nail on the head, if you want to keep your vision, in most cases, you need to stay away from the M&A scene. If you're looking to just make some cash or want a much larger exposure to the market knowing that you may lose some of that "somethin', somethin'" then M&A may be right for you.
Something to keep in mind here is that the internet does allow for a great "grassroots" style exposure method. While the phrase it overused and overassumed, "your stuff could go viral!!! OMG!"
Fourth- in the interview Trent provides some notes about what artists starting out can and should do. This is not unlike the technology industry. Now-a-days there is often very little capital required to start. You can literally buy a domain and hosting for 21 dollars a month, throw up a blog, software, etc. and you're on your way. The most expensive equity at that point becomes sweat equity. Here is something to note, investors tend to like it if you require less money from them and can produce something which will make them rich. Seems to make sense yea? If you can show that you work your ass off, made this product in your "free" time, and then have plans for the future, you're well on your way to getting some funding.
Keep in mind that getting funded is much like acquisition. While the investor will be much more likely to care about your vision they are still concerned about the profit engine. However, because it doesn't feed into some conglomerate view of the bottom line, there is a bit more attention on the details that make your company tick.
Fifth- things are changing. The way that business is done is changing. This is somewhat hidden in my fourth note. Trent noted a distinct difference with the way artists need to operate now from when he was coming into the industry with Nine Inch Nails. The technology that exists today makes it so that the companies today that are really taking off are just starting as hobbies or sideprojects. There are a ton more as well. The point here is that these companies are utilizing the infrastructure to make something really interesting and really useful, but most importantly, something that they themselves want to use. This is where I see technology companies going.
There are a few things about this topic I haven't elaborated on. If you make something that you yourself want to use then you will likely lack passion, devotion, and when the chips are down it'll be easier to cashout than to dive back on in. Starting projects, companies, or ideas is hard work. It requires a ton of time and effort. You'll get to a point where it will feel better to just throw it away. But, if what you are doing is worth it to _you_ then you will pour that extra cut of "oomf" and push through it. And, IMO, if investors overlook this crucial element, they don't deserve the profit you would make them. :)
Linux has some great software built for it and the video editing arena is no different. The videos that I create tend to be fraps based out of games, but they still require some editing. I was interested in finding some software that wasn't hard to use and would allow me to produce quality videos.
Enter Kdenlive. Kdenlive is a non-linear video editing tool that provides nearly everything that an amateur like me would want. And, having seen Adobe Premiere Pro, I'd imagine it's what professionals want as well.
The software itself is laid out really well. My focus and attention is always on the video itself. And, since the second area where I do most of my detail work is with the tracks, it only makes sense that it be very large as well. The project tree, left of the video, can be toggled for other things as well. You can view the effects and the transitions lists in this pane. Then, should you want to add something you can drag it in place.
I have checked out some other software before too but it was incredibly buggy and way too crashtastic. The one I tried the most to use was OpenShotVideo and it just isn't there yet. It seems like it could be a great tool in the future. For now, this novice is sticking with Kdenlive. :)
At any rate, I'm not great at "reviewing" video software since I do so little of it. I just wanted to throw out a post mentioning the capabilities here in case others of you who do the same thing I do with video were interested in it. I hope that this is helpful to someone.
Software development is always a good way to realize that you're human. I'm sure there are other professions that give you this feeling as well, but my experience is limited to the software development field so I'll talk about it from that light. There are really two ways to go on this subject. I could talk about code rot and the need to clean it up and/or talk about test driven development. Because I think they both have something to do with each other, why not make it about both eh?
The Church of TDD
Test Driven Development is a nice concept. The key here is concept. The idea here is that you write tests for a piece of functionality (ideally you know what you're trying to get out of your function) and then write the actual functionality such that all your tests pass when your functionality is complete. Why you might ask? Well, I'll answer! The reasoning is that when you're 3 months into your project, breaking Brooks' law, and trying to cope with the ever changing requirements of your project, you'll simply have to make your change and re-run your tests. If they fail, you caught the problems at test time rather than at 3 AM when your boss friend calls you up and lets you know that he was just informed about emails being sent around to customers with usernames, email addresses, phone numbers, and contact lists for about 500,000 users.
Obviously a made-up case, but I have read about similar scenarios. That said, test driven development is only useful when you're testing the right things. Testing functionality isn't just about testing that you get a string back in all cases. Let's say your working with Java and StringTokenizer's. You might need to test the return values of each token. Also you may have to test the number of tokens or if a token is supposed to be empty that it isn't null. If an exception should be thrown, you should check that case too. There are plenty of example cases to check here, but the point is that if you're testing a method and only checking that something was returned then you aren't finished.
Start out with a plan. This works in either the agile or waterfall methodologies. By this I mean, think about what you are about to produce. It usually helps me to take a step back and process what the method is expected to do. "What do I expect to see when I call x()?" "What assumptions do I seem to be making about x() where I'm calling it?" Running through questions like these are a good way to get a base set of tests for your functions.
So now you have a handful of tests that should make sure your code works right? Right!?!? Not necessarily. Let's go back to my first line here. "Software development is always a good way to realize that you're human." You'll miss something. It's inevitable and, what's better, it isn't because you are bad at what you do. There are so many other things that are likely going on in your brain. If you are anything like me the whistle of a dart flying by your head or the ping and the pong of a game going on in the distance is enough to bring you out from your "I should write tests" concentration. What's more, there are just going to be cases that you miss. It is O.K. to miss things, but there is a stipulation here. When you do and when it is caught, you need to write a test that checks for the situation/case.
Subscribing to TDD for the sake of it wont get you far and will likely slow your productivity. But, if you take a pragmatic approach to TDD and write tests as you think of cases your source base will likely be more stable since you'll find bugs when you run the tests instead of through the client. And, you'll have a system in place for those bugs that do slip through so that you can make sure they don't come up again. Clients are a lot less understanding when you have issues with your code base and you can't assure them that you wont ever have that problem again because you have no tests in place to ensure it.
Code Rot and Technical Debt
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. - Ward Cunningham on Technical Debt
Software development is one of those knowledge based fields. You write software with what you know at the time. If you are any good at what you do, you should still be learning every single day. The old saying "you can't teach an old dog new tricks" really doesn't hold water in this industry. Once you stop learning new things, techniques, and methods, you've effectively signed yourself into retirement or unemployment. That is just the way our industry works.
So, with this new-found knowledge and all powerful ability you'll begin to smell something. It's a familiar smell. You'll be working on your code base and look at a method you wrote a couple weeks ago and have to plug your nose. That, my friends, is code rot.
The two, technical debt and code rot, are interesting. Understanding that you may take shortcuts to get a project moving only works when you refactor. If you do not refactor your code after you've introduced the questionable code you're in for a "fun" time.
Lets not get the two confused. Code rot is typically when things change external to the code such as your ability to program or changes in the industry that your software works with. Technical debt tends to be what you introduce knowingly to the code with the intention of cleaning up later. However, as you find code rot, it becomes technical debt when you do nothing about it.
Technical debt is something that needs to be paid back. Relating this to real life; imagine yourself going so far into debt that you cannot imagine yourself ever getting out from under the load you carry. You will either be stuck with extreme payments the rest of your life or you'll claim bankruptcy. In a software project, the equivalent of bankruptcy is a complete rewrite. You have invested time, sweat, tears, and likely a decent amount of money into whatever you're working on. You don't want to lose what you already have, but sometimes it's inevitable.
The point I'm trying to make here is that you need to be willing to pay back your technical debt such that when you incur more debt, you aren't overwhelmed by it. Paying that back can be related back to time and effort. Hell, even if you spend 5-10% of your time just refactoring your code you'll have been paying back some of the incurred debt.
I'm probably beating a dead horse here so I'll move on.
Problems
There are always issues right? "Sure, what you're saying makes sense, but we don't have the time or the budget to go through our code and fix it." I know. I've heard and said this before. But, think about it like this.
I have a car. I drive it places and it serves me well. I put gas in and all is right in the world. Then one day I feel some light vibrations when I press the brake. I don't think much of it because the car still _works_. I don't have the time to get it taken in to the shop. About a week or two later I feel a stronger vibration and every so often some squeaking coming from the car. Again, no time- I'm a busy man! Another couple weeks pass and now the squeaking is a screeching and it's loud. It pierces my ears. I know that sound and realize that it means I likely need to fix more of the car. Now things are getting pricey and I don't have the money to fix it all at this point.
You see what's happening? I put it off so long that it became prohibitively expensive to surgically remove the rot. Instead now it is going to cost me a fair amount of cash, time, and effort to actually get these fixed. And, who knows, if I continue on the current path I might end up in a wreck.
Still when you are under constraints that you have very little control over there doesn't seem to be much that you can do. Most of the time you are forced into situations where you either piss off the PM's and management or just continue to let the code grow it's warts. Ideally, you'll prove to those that make time and budget based decisions that your changes will be worth it. By worth it I don't mean "the code will be better", I mean "in the long run, we'll say 30% and gain 5% in revenue".
Solutions
One of the serious mistakes that developers make with manager types is that they think they are relating to them with terminology and analogies. Typically it requires actual impact to prove that you are right. In order to get impact values you have to gather some metrics. Hopefully some of what follows can help there.
If you already have tests in place for the code you've written you can do a couple of things. Lie to the people that are asking you what you're working on. *cough* working on that scalable synergistic thing-a-ma-bob that will grow our profits exponentially *cough*. Or, you can tell them the truth. Regardless of what you do, you can have some faith in the fact that your system should operate in the way you expect it to because you have tests in place for just this reason. At some point this code was going to be changed and you wanted to make sure that you did some CYA when it did change.
If you don't have tests you can again, lie to the people. Or, you can explain to them why it is important and some tactical approaches to solving the problems. Some fuel for the fire:
Think about things like this. You want to get rid of this technical debt. It's very likely that the project manager does too. But, explaining these things to the people who are interested in release dates can be challenging. Try explaining that customers are more happy when their software works. The more you can ensure that the better. Often it'll require charts and figures with bug numbers over time. Be sure to show where you're making improvements too. For instance, "as you can see we refactored the code on 3/12 and the number of bugs being reported decreased by n%". By doing this, you are effectively showing ROI and how your changes affect the bottom line. For people concerned mostly about money that is important.
And, if all else fails, show them this video!
Sometimes it's better to just ask for forgiveness in doing these things. Even if it means temporary irritation, the benefits outweigh the downside.
0 Comments