Workling should get the items from the queue and send them out. It ran into the problem to not finding the RAILS_ENV.

The solution was as easy as this:

run "export RAILS_ENV='#{rails_env}' && #{latest_release}/script/workling_client start "

If you find youself in this situation: Don’t just write in environment.rb:

ENV['RAILS_ENV'] ||= 'production'

It will annoy you later - for sure

The idea was to be able to select tags that were already in use (because it’s likely to use them over and over again). So I build a small jQuery plugin that does exactly this job:

What you basically need is a text field. I post my Rails code here:

<%= text_field_tag :tag_list, value,
  :class => 'text_input',
  :id => identifier_field,
  :onfocus => "jQuery.taginput.showTagList('##{identifier_field}', '##{identifier_popup}')",
  :onblur => "jQuery.taginput.hideTagList('##{identifier_field}', '##{identifier_popup}')",
  :oninput => "jQuery.taginput.setAlreadyUsedTags('##{identifier_field}', '##{identifier_popup}')",
  :autocomplete => 'off'
%>

And a bit HTML code to prebuild the popup (This could be done with jQuery, too):

    <% if tags.size == 0 %>
      <%= t(:'view.relations.edit.tags.no_tags_info') %>
        Put some tag suggegstions here...
       <% tags << "friends"%>
    <% end %>

    <% tags.each do |tag| %>
      <%= "onclick=\"jQuery.taginput.addTagToField('##{identifier_field}','#{tag}', '#{identifier_popup}');
         return false;\""%>><%= tag %>
       <% end %>

    <%= t(:'view.relations.edit.tags.separate_by') %>

Alright, go ahead and check it out for yourself. The code is pretty basic and there’s a lot of space for improvement. If you have any suggestions, post a comment!

jquerytaginput-10

So what I came up with was a rake task that merges a give structure (YAML source file) into an existing target structure while overwriting every key that changed and adding new keys. Old keys and values are left as they are.

I didn’t find anything on the internet doing this task, so I hope this task will save you the time I spent last saturday. Good luck!

$KCODE = 'UTF8'
require 'ya2yaml'

namespace :quassum do
  desc "Copy all missing lang identifiers from [src].yml to [dest].yml"
  task :fill_lang do

    if ENV['src'].blank? or ENV['dest'].blank?
      puts "Give all parameters: src and dest. " +
        "E.g.: rake quassum:fill_lang src='de' dest='en'"
      exit
    end
    src_path = File.join(RAILS_ROOT,'config','locales', "#{ENV['src']}.yml")
    dest_path = File.join(RAILS_ROOT,'config','locales', "#{ENV['dest']}.yml")

    unless File.readable?(src_path)
      puts "File #{src_path} not readable!"
      exit
    end

    unless File.exist?(dest_path)
      puts "File #{dest_path} does not exist. Creating it..."
      File.new(dest_path, "w")
    end

    # We assume that the src file is correct...
    yaml_src = YAML::load_file(src_path)
    struct_src = yaml_src[ENV['src']]

    # ...but the src not necessarily. So, in case, we create a new lang file:
    @yaml_dest = YAML::load_file(dest_path)
    @yaml_dest ||= Hash.new
    @struct_dest = @yaml_dest[ENV['dest']]
    @struct_dest ||= Hash.new

    # merge all unknown changes to the dest struct:
    merge_recursively struct_src

    @yaml_dest[ENV['dest']] = @struct_dest
    File.open(dest_path, "w") do |file|
      file.puts @yaml_dest.ya2yaml
    end

    puts File.new(dest_path).read
    puts "Everything done."
  end

  #
  # SOME HELPER FUNCTIONS
  #
  def merge_recursively(pairs, parents = [])
    pairs.each_pair do |k,v|
      # copy the parents path and add the current element key:
      current_path = Array.new(parents) << k
      if v.is_a?(Hash)
        merge_recursively(v, current_path)
      else
        ensure_yaml_contains(@struct_dest, current_path, v.to_s)
      end
    end
  end

  def ensure_yaml_contains(element, path, val)
    #puts "    ensure_yaml_contains(#{element}, #{path}, #{val})"

    if path.length == 1
      if element[path.first].is_a?(Hash) and not val.blank?
        puts "Hash found instead of key. In favor of '#{val}' '#{element.to_s}' will be deleted!"
        element[path.first] = val
      end
      if element[path.first].nil?
        puts "Missing key '#{path.first}'! Pre-filled for editing with: '#{val}'. element was #{element.class}"
        element[path.first] = val + " [[TODO]]  "
      end
      # if none of these replaced anything - we're fine, the key exists!
      # 
    elsif path.length > 1
      # walk down if possible:
      if element[path.first].is_a?(Hash) and element.has_key?(path.first)
        ensure_yaml_contains(element[path.first], path[1..-1], val)
      else
        # We don't have a hash in the dest file, so we create the hash
        # and fill in all subsequent children:
        element[path.first] = Hash.new
        ensure_yaml_contains(element[path.first], path[1..-1], val)
      end
    else
      puts "REPLACING FAILED"
      # should stop here
    end
  end

end

• Keep the launch of products quite till the actual release day, then ship fast.
• Don’t discuss about rumors, even try to shut down rumor distributors.
• Update products every few months but keep the actual development closed from public.

Before every release event it seems that half the tech world is anxious knowing what happens, talking and speculating about their new stuff. Thus apple nearly limits their marketing expenses for the existing products while getting the hype for new releases for free.

Now, you could tell that the early adopters are always there after a certain base was established. Might be valid for Apple, yes. But this is not so true for the new operating system:

• Snow Leopard is said to be modified just “under the hood”. In fact, they moved from one software architecture to another while not changing the usage of the programs itself. Mail and other office programs are said to run a bit faster.
• As said before, they announced Snow Leopard already this year. Since they’re already beta testing it they can’t keep it secret.
• They needed an open specification to get hardware manufacturers under one hood, to align them using that specification later on.

So - what do we learn from it? Apple is using this open specification to succeed with their idea of multi-core computing. Apparently a good idea since it is dependent on the software developers using the underlying mechanics of the operating system. Moreover there aren’t any competitors being able to misuse this information.

And: Although Apple was announcing Snow Leopard pretty early, they’re still saving on marketing. It may well be that Snow Leopard will be a minor launch like any other new iPod generation with minor improvements. But I’m having the feeling that they’ll be getting something more out of it. The idea of using every computing unit of a computer (CPUs and graphic processors) is too tempting not to use it as a selling argument. I’m anxious to watch the process next year.

• The project management of a company is a great failure. They’re hacking from “hand to mouth”, not knowing where the aim will be tomorrow. Hiring the 1k/day consultant who’s an experienced XP project manager won’t bring the team any close to agile method if the company structure is based on strict hierarchies and envy is destroying the communication.
• Social problems, general unhappiness with life, loneliness or poverty that some people experience can’t be solved by any external means. That’s why many people are stuck in the process of longing instead of finding a partner. That’s why the dole rather help people stay alive than make them earn their money themselves.

Just like the famous saying from Gerald Weinberg:

“no matter what they tell you, it’s always a people problem.” (from coderenaissance.com)

Adapted to my points, this means watching a problem always mirrors the people in that situation. It’s just not honest saying “The codebase is too complex, we can’t ship the product”, it’s rather: “We really fucked the situation up. But Why? Because we’re afraid to ship? Because our employees hate us and thus produce bad code?”.

So that’s the point where any solution from would come in handy. And even if those from outside look easy, cheap and fast, they never work. The stylish third-party framework, the new Middleware, the bought-in code guru or even the the handsome guy from the online dating page.

It’s like solving the problem directly from the top of the 5 Whys. Too easy, too fast. Won’t work because the main reason for the state they want to escape isn’t tackled.
If there are suggestions of getting help from outside, always double-check if it’s really a needed resource to being able to chance the internals or it’s rather a mean to cover something and ignore the real thing.

Why not to

How many successful startups do we know that still have founders working as employees in other companies, do excessive consulting jobs aside or even studying at universities? Nearly none? There may be reasons:

Let me mention some things not to do. The number one thing not to do is other things. (Paul Graham)

Another reason can be if you want to get rid of a project really quickly. Spending all your time on it can accelerate your process. But there’s still the distance issue, see below:

Benefits

Working on one thing makes your mind get stuck on this topic. A mathmatician friend of mine once pointed out that’s nearly impossible to rework a math class in some days of vacation because there’ll be a lack of distance. That’s why pair programming is so popular in these years. While one developer programs the other is able to see the big picture of the task with a lot more distance.

Concerning everyday life, people have hardly just one thing that’s bugging them. Trying to go for the one solution often ends up in forgetting about other factors. Being able to work in parallel will not only take them a step further to their goals it also makes excuses obsolete (which is, in this case, probably the main benefit).

Moreover, it’s possible to plan for that parallelization. In fact, according to a german study most of their students are able to study and have a part-time job. I consider this as a much better practice than working in advance, saving money and study eventually. Anyway, most of them will face the distance problem and stick to their full-time jobs.

Distraction and scope

We know that parallelizing work is hard. It slows us down, we don’t have to argue on this one. But what about parallelizing projects? Projects often have the nature of having gaps in between actions. That is, for example waiting for the next lecture when working on the diploma/master. Working on other projects then requires a fair amount of scope. A factor that says, how much concentration you have for a specific task. There are methods to help not getting distracted by other things.

Matt Wood states another important point:

But the trick isn’t cutting out that distraction completely, it’s acknowledging it, admitting its power over you, then drawing lines and finding its proper role in your life.

Which is probably the greatest benefit we’ll get out of working in parallel. While the uni gives me inspiration, contacts and much theory, our startup shows me what we’re learning for.

There is a feature of Mac OSX that’s fairly underrated: the usage of avatars throughout the system. The benefits of maintaining those small images are become apparent subtly:

That’s just a small area of my two-screen setup but probably the part I work with the most. I configured Adium that it displays rather my own avatars than the messenger’s ones. It got much easier to figure out who’s online without even glancing on the names.

Avatars online

Let’s take a look at the web… (at my favorite social app)

Okay, apparently the benefit of recognizing contacts without reading the actual name. People change their profile as often as it causes the application to list their profiles higher than others.

What’s the deal then?

Some pages extensively use avatars (taken from mashable)

Do you see the benefit? It certainly isn’t the one I stated. When picking avatars randomly users just can’t match them with their contacts, especially if their “friends” change them hourly.

But: many avatars (and icons) can improve the impressions a basically dark page leaves. Or just look at photo pages like flickR; nothing but user generated graphical elements.

To a much greater degree, the merit is rather a psychological one: To the user the site shown above makes the impression of vividness, showing the presence of a boatload of users, just waiting to get in touch. If there’s the opportunity to get your user’s (or friends’) avatars, use them to create a better experience on your desktop or even your social network.

Skimming

Going through the whole script writing dependency record cards for every corollary, lemma and theorem. Those cards are plain records cards (title and details on the backside), additionally with dependencies to other cards on the rights border. A card now looks like this:

Additionally it’s possible to set flags on cards. For example: if there is an evidence to learn, mark the upper left corner black.

After skimming we produce a nice pile of cards. For a script of approx. 100 pages I used 90 cards.

Arranging the Tree

Alright, now we got our cards. We’re sitting in front of a cleared table and throw them onto it, one by another. Since our cards have various dependencies we should be getting a graph. Just to keep it simple we assume that we got a hierarchy and draw lines by exactly one dependency for each card (except the root(s), they have obviously none). Now we have a cluttered table:

Okay, that was a nice attempt. As said, there’s no point of arranging 90 cards on an average desk (If you have less, you might be fine with that). Apart from that there’s a nother problem: we can’t see the dependency / hierarchy lines. Ok, let’s go digital:

Mindmapping the lecture

There are some nice apps for OSX to create a mindmap. On that occasion I moved away from mindnode to freemind (I just had to rearrange nodes). Additionally freemind is java and thus available for other platforms. Neat!

After typing everything in (with some shortcuts at hand it’s not that painful) we print the whole map on three sheets:

That process takes some time. But with this outline we’re not only able to see the outline of the whole matter, in fact we can learn specifically by browsing through the nodes in depth-first-search.

Ever wondered why there is such a thing like refactoring? People seem to like implementing quickly and refactor afterwards. Ever wondered if we could do this in a single step? Or at least hack the stuff just one time?

The programmers I got in touch with hardly write something down before they implement. I also often feel like hacking when I first see the solution of a problem. But that’s the first step of getting yourself into trouble.

What we could do is write before we code. Write the solution. Not just the outline, the comfy part, write down the complex structure of the whole solution.

“Writing things down shows you how sloppy your thinking is” says Leslie Lamport advertising the model-checking enabled TLA+, which is mainly designed for developing algorithms. I’d strongly agree but drag that idea to a more generic level:

Debug at the thought level! For every implementation, for every two classes you inherit, for every step you want to take in you career, for everything you feel too sure about. Write it down. See the output of you brain manifest and watch yourself thinking over it one more time.
If it’s not the IDE you commited your initial sloppyness to, you probably save a lot of time!

But as we moved from static content to dynamic pages where you can hardly distinguish the resources, we needed parameters:

http://zazazu.de/zazazu.php?sde=100&per=338

Now what does this tell us aside from the URL? Apart from the fact that someone used PHP - not much but noise. Come on, we can do better. Here’s the why:

• If you offer your users a unique profile, these adresses are shown around. Make it most comfortable for them to do so.
• The does better understand direction of the content. xyz.com/games/pacman is much more exact than xyz.com/games.do?gid=4711.
• It simply looks better.

There are some simple, some profound principles in declaring your page’s URLs. Basically there’s a solution for every platform:

Ruby on Rails’ routes, django’s equivalent, Cake’s router… If nothing helps, a webserver can rewrite the URLs on its own, e.g. with mod_rewrite. So there are plenty possibilities. And then, the concept of your web application has to support the resolution of names instead of ids or other parameters.

For example, a website can link to their profiles with /profiles/id/1339 or it can dispatch them with names, like linkedIn.com (using Java, Spring and JSP):

And, unless there are reasons to “disclose” the world from mapping URL to profile names you should avoid this kind of profile URL: http://www.studivz.net/Profile/e094a153d4af2fc6 and let the users spread their profile URLs with as much eagerness business cards. Compared to the whole code in your webapp it isn’t a great change but (apart from looking more professional) your website will get a happier usage.