[Be el o ge]

random stuff about web application development … and more :-]

[Be el o ge]

Don’t Just Roll the Dice – Neil Davidson

March 14th, 2010 · No Comments

Neil Davidson’s book is an excellent, short, easy to read guide to software pricing. It all starts with some very basic economics: what’s the best middle ground between quantity (number of sold products) and price. At which ratio can you maximize your revenue?

Further Davidson advises that you should first think about what you actually want to sell. Better to say: What’s your actually product? In most cases this is not just the software, it’s additional services, support, reassurance and eventually many other things.

After these two introductory chapters, Davidson comes to to the core of the topic: Chapter 3 – Pricing Pitfalls: Keep an eye on your competitors, be fair to your customer and finally chapter 4: Advanced Pricing meaning: versioning, bundling, multi user licenses, site licenses and the popular freemium model. Last but not least chapter 5 talks about what the price of your product says about you and how you can change it if you don’t like what it says. The last chapter is a very useful checklist about product pricing.

The book is available for free on the web or you an buy a paper copy at Amazon.

  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: Books

Die Kunst über Geld nachzudenken – André Kostolany

March 14th, 2010 · No Comments

“Die Kunst über Geld nachzudenken” ist André Kostolanys letztes Buch und jeder der sich für die Börse interessiert sollte sich zunächst dieses Buch zu Gemüt führen bevor er zu irgendeinem anderen Buch über dieses Thema greift. Was nicht heißen soll das viel gute weiterführende Literatur gibt. Mit Kostolanys Buch bekommt man jedoch ein erstes Gefühl dafür wie die Börse funktioniert.

Themen sind unter anderem:

  • Einstellungen zum Geld. Wer wirklich zu Geld kommen will, darf _nicht_ denken, dass Geld stinkt: Geld stinkt nicht.
  • Börsenteilnehmer: Über Makler, Money-Manager, Finanziers, Arbitrageure, Börsenspieler, Anleger, Spekulanten.
  • Womit kann man spekulieren: Über Anleihen, Devisen, Rohstoffe, Sachwerte, Immobilien und Aktien.
  • Die Börse an sich. Geschichte. Inwiefern spiegelt die Börse die reale Wirtschaft wieder? > weniger als man denkt
  • Was die Börse bewegt: Es ist letztendlich lediglich der Mechanismus von Angebot und Nachfrage
  • Langfristige Einflussfaktoren: Friede ist das wichtigste
  • Mittelfristige Einflussfaktoren: Geld + Psychologie = Tendenz; Rolle von Inflation und Deflation
  • Börsenpsychologie:: Das Ei des Kostolany, die vier “G” des Spekulanten: Geld, Gedanken, Glück, Geduld. Um an der Börse erfolgreich zu sein muss man antizyklisch handeln.
  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: Books

C#: Bug in Uri.IsWellFormedUriString?!

February 27th, 2010 · No Comments

A few days ago I had to analyze a string, figure out whether it is a URI and if yes, then do something with parts of the URI, like the host, the pathname and the parameters. Since I was coding in C# I thought the Uri class would be just ideal for that.

So first I implemented this

Uri myUri;
try {
    myUri = new Uri(myUrlString);
} catch (UriFormatException) {
    // do something
}

Then however I realized that there is a function for testing the validity of a string:

Uri myUri;
if (Uri.IsWellFormedUriString(myUrlString)) {
    myUri = new Uri(myUrlString);
}

This is much nicer. I don’t like using exceptions to handle expected workflows. In this case the string can be a valid or invalid Uri, so really the if-then-else construction is nicer than the try-catch. The problem is that even though IsWellFormedUriString returns true you might not be able to create an Uri instance from it. Consider this small programm:

using System;
namespace DemoConsoleApp
{
	class MainClass
	{
		public static void Main(string[] args)
		{
			Uri myUri;
 
			string myUrl1 = "www.mydomain.de/test/file.aspx";
			string myUrl2 = "http://www.mydomain.de/test/file.aspx";
 
			Console.WriteLine(Uri.IsWellFormedUriString(myUrl1, UriKind.RelativeOrAbsolute));
			Console.WriteLine(Uri.IsWellFormedUriString(myUrl2 ,UriKind.RelativeOrAbsolute));
 
			try {
				myUri = new Uri(myUrl1);
			} catch (UriFormatException) {
				Console.WriteLine("Failed to create Uri from myUrl1");
			}
 
			try {
				myUri = new Uri(myUrl2);
			} catch (UriFormatException) {
				Console.WriteLine("Failed to create Uri from myUrl2");
			}
		}
	}
}

The output is :

True
True
Failed to create Uri from myUrl1

According to the documentation, the first call of Uri.IsWellFormedUriString should returns false. If it did this would be also consistent with the constructor, which fails for myUrl1.

By default, the string is considered well-formed in accordance with RFC 2396 and RFC 2732. If International Resource Identifiers (IRIs) or Internationalized Domain Name (IDN) parsing is enabled, the string is considered well-formed in accordance with RFC 3986 and RFC 3987.
The string is considered poorly formed, causing the method to return false, if any of the following conditions occur
[...]
The string represents a hierarchical absolute Uri and does not contain “://” – www.contoso.com/path/file

  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: C#

Firefox randomly adding _moz-rs-heading to a-tags

February 26th, 2010 · No Comments

I recently noted that some elements on my page randomly weren’t rendered like I expected even though other elements of the same CSS class were rendered correctly. Looking at the code I noticed that Firefox was adding weird tags to link tags:

<h1>
    <a _moz-rs-heading="" href="/lists/1?locale=en">Gute Weine</a>
</h1>

But not only that. The whole HTML structure was messed up.

The green area highlights a correctly rendered element like it was coded in the plain file. The red area highlights what happened randomly in Firefox.

After a bit of googling it turned out that this false rendering was caused by a mistake from my side: You should not wrap block elements like div and h1 with a link tag. So the HTML really should look more like this:

<li class="list" id="list_19">
    <div class="list_content">
        <h1><a href="/lists/19?locale=en">Einkaufsliste</a></h1>
        <div class="summary">
          <a href="/lists/19?locale=en">
              4 items in total, 3 items done.
              <br />
              Last updated 3 days ago
          </a>
        </div>
    </div>
</li>

In this code a-tags wrap only text elements. img-tag would be fine, too. Other elements you should avoid in order to prevent rendering you don’t expect.

It looks like amongst a lot of other cool stuff HTML5 will bring us also block-level links.

  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: HTML

Nasty bug when using your Rails / jQuery powered app with Chrome

February 20th, 2010 · No Comments

Today I ran into a nasty bug which is only reproducible in Google Chrome. In Firefox the very same code worked perfectly fine.

The code was supposed to work like this: After the user clicked the delete icon, jQuery would send an ajax request to the server, which then would delete the list. In the call back the UI gets updated by removing the list entry element. It’s as simple as that. The HTTP method was set to DELETE to be clean. In Firefox that worked great, in Google Chrome not at all. However you didn’t get a client side error, at least not at first, but a Rails error which would look like this:

Error occurred while parsing request parameters.
Contents:
 
[object Object]
/!\ FAILSAFE /!\  Sat Feb 20 18:56:39 +0100 2010
  Status: 500 Internal Server Error
  undefined method `name' for nil:NilClass
    /home/siebel/.gem/ruby/1.8/gems/activesupport-2.3.5/lib/active_support/whiny_nil.rb:52:in `method_missing'
    /home/siebel/.gem/ruby/1.8/gems/activesupport-2.3.5/lib/active_support/xml_mini/rexml.rb:29:in `merge_element!'
    /home/siebel/.gem/ruby/1.8/gems/activesupport-2.3.5/lib/active_support/xml_mini/rexml.rb:18:in `parse'
    /home/siebel/.gem/ruby/1.8/gems/activesupport-2.3.5/lib/active_support/xml_mini.rb:12:in `__send__'
    /home/siebel/.gem/ruby/1.8/gems/activesupport-2.3.5/lib/active_support/xml_mini.rb:12:in `parse'
    /home/siebel/.gem/ruby/1.8/gems/activesupport-2.3.5/lib/active_support/core_ext/hash/conversions.rb:164:in `from_xml'
    /home/siebel/.gem/ruby/1.8/gems/actionpack-2.3.5/lib/action_controller/params_parser.rb:34:in `parse_formatted_parameters'
    /home/siebel/.gem/ruby/1.8/gems/actionpack-2.3.5/lib/action_controller/params_parser.rb:11:in `call'
    /home/siebel/.gem/ruby/1.8/gems/actionpack-2.3.5/lib/action_controller/session/cookie_store.rb:93:in `call'
    /home/siebel/.gem/ruby/1.8/gems/actionpack-2.3.5/lib/action_controller/failsafe.rb:26:in `call'
    /home/siebel/.gem/ruby/1.8/gems/rack-1.0.1/lib/rack/lock.rb:11:in `call'
    /home/siebel/.gem/ruby/1.8/gems/rack-1.0.1/lib/rack/lock.rb:11:in `synchronize'
    /home/siebel/.gem/ruby/1.8/gems/rack-1.0.1/lib/rack/lock.rb:11:in `call'
    /home/siebel/.gem/ruby/1.8/gems/actionpack-2.3.5/lib/action_controller/dispatcher.rb:114:in `call'
    /home/siebel/.gem/ruby/1.8/gems/actionpack-2.3.5/lib/action_controller/reloader.rb:34:in `run'
    /home/siebel/.gem/ruby/1.8/gems/actionpack-2.3.5/lib/action_controller/dispatcher.rb:108:in `call'
    /home/siebel/.gem/ruby/1.8/gems/rails-2.3.5/lib/rails/rack/static.rb:31:in `call'
    /home/siebel/.gem/ruby/1.8/gems/rack-1.0.1/lib/rack/urlmap.rb:46:in `call'
    /home/siebel/.gem/ruby/1.8/gems/rack-1.0.1/lib/rack/urlmap.rb:40:in `each'
    /home/siebel/.gem/ruby/1.8/gems/rack-1.0.1/lib/rack/urlmap.rb:40:in `call'
    /home/siebel/.gem/ruby/1.8/gems/rails-2.3.5/lib/rails/rack/log_tailer.rb:17:in `call'
    /home/siebel/.gem/ruby/1.8/gems/rack-1.0.1/lib/rack/content_length.rb:13:in `call'
    /home/siebel/.gem/ruby/1.8/gems/rack-1.0.1/lib/rack/handler/webrick.rb:50:in `service'
    /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
    /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
    /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
    /usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
    /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
    /usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
    /usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
    /usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
    /usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
    /usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
    /home/siebel/.gem/ruby/1.8/gems/rack-1.0.1/lib/rack/handler/webrick.rb:14:in `run'
    /home/siebel/.gem/ruby/1.8/gems/rails-2.3.5/lib/commands/server.rb:111
    /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
    /home/siebel/projects/Memento/script/server:3
    -e:1:in `load'
    -e:1

Since the server returned a HTTP 500 error, the client side displayed a message to the user that an error occurred. That certainly was ok, but why the hack did Rails throuw an error?

I had to google a while till I found this ticket: Bug in Chromium with GET parameters when doing a POST request

So it looked like something is going wrong when you send URL parameters alongside during a POST, PUT or DELETE. Since I’m using a URL parameter to specify the locale, I first thought that’s the issue: http://localhost:3000/lists/14?locale=en. Sadly removing it didn’t help.
While searching through the code I realized that for non-GET requests I was adding data to the PUT, DELETE, POST URL by this code:

$(document).ajaxSend(function(event, request, settings) {
        settings.data = { SomeParameter: "value" };
});

Once I commented out this one line things started working. I could finally delete the list using Chrome. The question now: How do I send this additional data. Fun thing: I didn’t have to … it was already added by other parts of the code. So the real issue here was that I had two parameters with the same name in my request. This was gracefully handled but Firefox but not by Google Chrome.

  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: RubyOnRails · jQuery

The Principles Of Successful Freelancing – Miles Burke

February 20th, 2010 · No Comments

If you ever considered freelancing as an alternative to earn money, you might want to check out this book. It touches a lot of, if not all, parts you should think about before you start freelancing. It contains a rich set of resources for getting additional information and serves perfectly as a checklist you want check from time to time during your first year as a freelancer.

Even if you’re currently not thinking about freelancing the book gives you some good ideas about what everything is important in (web / it) business. It’s more then just programming and that’s maybe hard to understand for some coders: there’s marketing, sales, accounting, creating and maintaining partnerships, business development, taking care of legal issues and dealing with difficult customers. You scratch the surface of all that in Burke’s book. And for the beginning the surface might be just enough. I guess once you run your own business you’ll soon find out in which areas you need to get more information. Again, you can check out the additional resources mentioned throughout the guide.

An often heard argument pro freelancing is to gain more freedom compared to a solid job as an employee of a company. However to truly gain this freedom you need to strictly organize your time which means also separating private time from working time. In this book you’ll find examples and techniques to do so.

All in all a book worthwhile reading, no matter whether you really want to freelance or not.

  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: Books

Die kleine Stechardin – Gert Hofmann

February 15th, 2010 · No Comments

In “Die kleine Stechardin” schreibt Hofmann über das Leben des Göttinger Gelehrten Georg Christoph Lichtenberg. Es ist eine unheimlich menschliche Geschichte mit vielen Höhen und auch Tiefen. Es geht um Emotionen, Hoffnungen, Liebe, ganz einfach um das Leben an sich. Obwohl mit Sicherheit und eigener Aussage des Autors nicht alles auf geschichtlichen Tatsachen beruht, wirkt nichts gekünstelt oder falsch. Eine Geschichte, die man sich nach Möglichkeit nicht entgehen lassen sollte

  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: Books

Rails: DEPRECATION WARNING: @var will no longer be implicitly assigned to local_var.

January 31st, 2010 · No Comments

I just ran into an interesting warning and since it took me a few minutes to figure it out I thought I share it here.

I’m rendering a partial template like this:

render :partial => 'list_items/list_item', :locals => { :list => @list, :list_items => @list_item}

Now, when running this code I got this deprecation warning:

DEPRECATION WARNING: @list_item will no longer be implicitly assigned to list_item. 
(called from _run_erb_app47views47list_items47_list_item46html46erb_locals_list_list_item_list_items_object 
at /home/stefan/projects/Memento/app/views/list_items/_list_item.html.erb:1)

The problem here was that in the partial I’m using the local variables are named list and list_item, in the render call however I’m passing in list and list_items. Everything still works because rails implicitly assigns @list_item to the local variable list_item. This is what the warning says…

So the fix is simply removing the additional “s”.

render :partial => 'list_items/list_item', :locals => { :list => @list, :list_item => @list_item}

Not specifically hard but yet another prove that taking “a close look” at your own code is always difficult ;-) I bet a peer what have see the problem in a sec …

  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: RubyOnRails

Freakonomics – S. D. Levitt and S. J. Dubner

January 30th, 2010 · No Comments

Freakonomics promises to “explore the hidden side of everything“. Well, it doesn’t … obviously it can’t. Nevertheless it’s funny to read and there are a couple of interesting things in the book.

A few notes:

  • There are three different kind of incentives: moral, social and financial; Incentives are the cornerstones of modern life.
  • Everybody cheats, that’s nature.
  • The conventional wisdom is often wrong. Just because you feel comfortable with something it doesn’t mean it’s correct. Use hard data to check whether something is really true.
  • Dramatic effects often have distant, even subtle, causes.
  • Experts use their informational advantage to serve their own agenda >> information asymmetry

The final two chapters are mainly about parenting and children names … which was not particularly interesting for me, but might be for others. Just one thing: there’s almost no other area where false conventional wisdom is so widely spread like in parenting.

I’d say out of five stars it gets three.

  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: Books

Learning Rails: content_for

January 17th, 2010 · No Comments

Learning Rails on a real project (ListKungFu.com) is great fun and you’ll find out everyday something else which makes Rails the awesome framework it is. In the beginning of cause, that are rather small but unbelievable convenient things, in this case that is: The content_for helper command.

In an application as simple as List Kung Fu most views are structured like that:

So we have the ListKungFu logo, a profile and a logout link in the header and some notes in the footer. All this you typically would find in a layout file (application.html.erb) because it’s likely you wanna display these elements on each page of your application. The more page specific data is rendered using a template, in this case show.html.erb.

List Kung Fu uses a fair amount of Javascript. My first approach was putting everything in a single .js file and loading it in application.html.erb. That’s ok for the beginning but becomes pretty soon pretty ugly. First, you end up with one big Javascript file which is not really nice for maintaining, second and that’s much worse: The user’s browser is loading the Javascript code for the complete application even though just a fraction of it is used per page.

Obviously the first thing you wanna do is splitting up the big Javascript file. My splitting strategy goes like this:

  • Code which is used all over the application and which might be useful even in different applications I put into application.js. This file in included in the layout file.
  • Second, I created a file called listkungfu.js containing Javascript which is also used over the whole application but is more specific and therefore unlikely to be reused in another application.
  • All Javascript code which is specific to just a small part of a application, e.g. a single view, I put into a separate file. Following above example there is for instance a file called lists_show.js for the show.html.erb view.

All we have to do now is including application.js and listkungfu.js in the layout file and lists_show.js in the view template.

< %=javascript_include_tag 'lists_show' %>

Done.

Hm… after loading the view in the browser and looking at the generated HTML you might not be satisfied a 100%. The Javascript files included in application.html.erb nicely line up at the bottom of the page, but lists_show.js is loaded somewhere in the middle of the HTML.

So, how do we move it down? You might have guessed it: content_for to the rescue!

Let’s replace above code with:

< % content_for :addtional_scripts do %>
    < %=javascript_include_tag 'lists_show' %>
< % end %>

And yield the content at the end of the layout file:

    < %= javascript_include_tag 'application', 'listkungfu' %>
    < %= yield(:addtional_scripts) %>

After reloading the view in the browser you’ll find the view specific Javascript file loaded after the two general files.

Very cool!

content_for can be used for a dozen other things, too. Think about having a side bar defined in the layout displaying view specific information, etc…

  • Delicious
  • Twitter
  • Facebook
  • LinkedIn
  • Gmail
  • Reddit
  • Slashdot
  • Technorati Favorites
  • Digg
  • Share/Bookmark

→ No CommentsTags: RubyOnRails