casperfabricius.com

Get a copy of all outgoing ActionMailer emails

Casper Fabricius — Fri, 06 Nov 2009 17:21:38 +0000

People care about emails. They don’t like to be bothered with emails they find unimportant, especially not if they are sent by mistake, have the wrong content or looks weird.

Many of the applications we build send out a lot of emails, and for some, it is a critical part of the system. Lokalebasen is such an application, and the people behind wanted to monitor all outgoing mail, whether generated by a page request, a cron job, an administrator or anything else.

I built a clever little monkey-patch for the Ruby on Rails ActionMailer that makes sure that all outgoing emails has a certain email address put on BCC. This is not visible to the recipient, but it allows you to keep an archive of all outgoing mail, which is certainly useful – especially for support and bug-tracking.

Drop this into your lib-folder (remember to change the email address):

- and be sure to enable it by adding this line to environment/production.rb (you probably don’t want to BCC mails sent in development and test mode):

ActionMailer::Base.send(:include, BccAllMails)

Hosting a Spree webshop on Heroku

Casper Fabricius — Sun, 18 Oct 2009 13:09:46 +0000

Spree is the webshop solution for Ruby on Rails, and Heroku is the place to host your Rails-applications – especially if you like free hosting :)

Finding myself in the need of a webshop, I decided to try to deploy Spree to Heroku. It wasn’t too hard, but it did take a few tricks to get Spree running on a server that doesn’t allow you to write to the file system.

I can’t say I have too much hands-on experience with Spree yet, but it seems to be have borrowed its extension concept from Radiant CMS, which happens to be one of my areas of expertise. So I put together an extension for Spree that will easily allow you to deploy the e-commerce system to Heroku.

Just follow the instructions in the README on Github.

Manage and rollback Heroku deployments Capistrano-style

Casper Fabricius — Sun, 20 Sep 2009 14:36:17 +0000

If you are a Rails-developer, and you don’t know about Heroku, now would definitely be a good time. Heroku is a platform for hosting web-based Ruby applications in “the cloud”, in this case Amazon EC2, making you able to scale your application in an effortless and cost-effective manner without worrying about the hardware behind. Heroku differs from competition by offering by far the fastest and easiest way to deploy your Rails-application. You simply create your application from Heroku’s web interface or using their API, and then push your git-repository to Heroku’s git-server. Heroku takes care of the rest, and you can get back to coding.

I use Heroku for My Big Secret Project, and I am quite happy with not just the ease of deployment it offers, but in fact also with the choices and the constraints that the platform imposes on me. I like writing git push heroku and see my code live immediately. This is of course not that different from Capistrano, once that has been setup with the right recipes and the server has been setup to corporate and serve our web application properly. But that can also take some time, especially on a brand new server.

I did miss one important feature of Capistrano when I started using Heroku: Rollback. Writing cap deploy:rollback has saved my behind many, many times. Granted, it has often been because of bad server configuration which shouldn’t happen with Heroku, but there has also been cases of genuine bugs resulting in all pages returning errors. When we do mess up, it is really nice to have the application back up in a matter of seconds, and then being able to take you to fix the error – perhaps even do the right thing and write a failing test for that particular bug before you fix the error.

With Heroku you don’t get rollback per se, as the application always displays the HEAD version of the master branch in the git repository on Heroku’s servers. However, with git we have the ability to roll back to the state of every single commit ever done. It’s just not very convenient having to figure out which commit was your last one working, especially not in a situation where your application is down. Also, we need this to be automated like everything else.

The solution I came up with was to tag each release with a timestamp – just like Capistrano names its release directories. This gives me a series of tags that should all point to successful deployments, and when my hour of distress arise, I can simply tell the master branch on Heroku to point to the previous release. If I further delete the tag of my current release, I have effectively rolled back to my previous release, and hopefully my application is now up and running again.

If you want this functionality in your Heroku application, just copy the above code into a .rake in your lib directory. You deploy your application with this command rake deploy and roll back with rake rollback.

Please note that the script also runs migrations on each deploy, but feel free to delete that line. Suggestions and improvements are very welcome. Enjoy.

Test-driven Rails development with RSpec, RR, Shoulda, Factory Girl and Stubble

Casper Fabricius — Sat, 25 Jul 2009 16:44:45 +0000

When I recently started development of a new, big Rails project, I spend some time researching and considering the many different testing frameworks that are available in the Ruby community today. I have grown very satisfied with the fail/pass rhythm of test-driven development (TDD) – write a test that fails, then write just enough code to make it pass. I also like RSpec a lot, so some would say that I am fact doing behaviour-driven development (BDD) – to me, the only real difference between TDD and BDD is the syntax, and I tend to find RSpec’s examples slightly more readable TestUnit’s tests. TDD gives me a small gratification – a sense of accomplishment, albeit on a small scale – every time a test passes in my autospec terminal.

Howver, TDD’s basic rule of always writing a failing test before writing any new code, doesn’t always leave me feeling very productive. For this reason I have mostly abandoned testing views in isolation (as made possible by RSpec’s view tests), as well as testing Rails helpers with the exception of complicated helper methods with some business logic in them. I still tests views by, behold, viewing them in the browser, and I haven’t been swept away by Cucumber, Webrat, Selenium and their fellow high-level test frameworks yet – but I am open.

I can skip view-testing without feeling too bad about it (wonder how many potential customers that statement scared away), but although I live and breath by the Skinny Controller – Fat Models notion, I still find functional testing of my controllers to be a must in Rails TDD. Unfortunately, I have never really gotten along with RSpec’s default way of testing controllers. It feels bloated, and the RSpec mocking framework seems to – yes – mock me as I add more and more stubs and expectations to avoid tests from failing. So in my research for testing frameworks, I knew I had to find a better way to feel productive and happy about writing controller code again.

Many people hate test fixtures in a very intense and passionate way. I actually kind of like them, I just think they are a bit too stupid and hard to maintain. I also love all the good stuff coming from the thoughtbot guys, and their alternative to Rails’ fixtures – Factory Girl – is really, really good. Not just because it has a pretty name and a fancy syntax, but because it is really nothing more than Rails’ fixtures done right.

I am getting ahead of myself here. Testing seems to be something people have very different opinions about, and as such I don’t the perfect mix of testing frameworks for everyone exists. RSpec has probably come closest, and I am sticking with in my test setup while adding and replacing parts of it with newer and better solutions. The mix has come like this:

RSpec as the overall testing framework
RR (DoubleRuby) for mocking and stubbing
Shoulda to get sweet test macros
Factory Girl to create test data
Stubble for easing my controller spec pains

Do I really need five testing frameworks to be productive with TDD? Not at all, Rails is bundled with all I need to do TDD. But along the way, I have seen the need to make my tests DRY’er, more readable and easier to maintain, and these frameworks help me with that in different ways. I have already touched on the RSpec vs. TestUnit issue: It comes down to personal taste, and RR, Shoulda, Factory Girl and Stubble all works with both of these frameworks – isn’t that nice?

I initially chose to try RR because it seemed to be what the cool kids are using at the moment (and that often turns out to be good), but now that I am getting into it, I am really starting appreciate its compact syntax and advanced features. You could argue that RR’s syntax:

  mock(User).find { @user }

- is much harder to read than, say, RSpec’s mocking syntax:

  User.should_receive(:find).and_return(@user)

- but I’d say that RR’s syntax is actually more “Ruby-ish” than RSpec’s. If you really understand Ruby, RR will most likely appeal to you.

I use Shoulda mainly to get DRY’er tests that are easier to read, than when I write macros myself. Shoulda has defined a set macros that are quickly becoming a standard, and as something quite new, they also exists as RSpec matchers. Statements such as:

  it { should validate_presence_of(:state) }

- simply makes TDD faster and more enjoyable, because it would feel wrong to have to write 3-5 lines of test code to test a single line of Rails code.

I can’t say if Factory Girl is better than, say, Machinist (which is actually heavily inspired by the former, according to the creator), but it is without a about much better than Rails’ fixtures from maintenance point of view, the syntax is pretty and it feels productive to use.

If you already knew about everything else mention in this article, chances are that Stubble will still be news to you. Not even released in a version 0.0.1 yet, this project is a small testing framework aimed at making stubbing and mocking in controller tests much easier. When the author, David Chelimsky – who is also behind RSpec – mentioned this in passing at a presentation at RailsConf 2009, my curiosity was immediately piqued. Could this be solution to functional testing woes? Short answer: I’m not really sure yet. It’s still too early to say. Currently, I can only get Stubble to work in very simple cases like this:

  describe "on GET to :show" do
    def do_get(params = {})
      stubbing(Teaser) do |teaser|
        get :show, {:id => teaser.id}.merge(params)
        yield(teaser)
      end
    end

    it { do_get { |teaser| should assign_to(:teaser).with(teaser) } }
    it { do_get { |teaser| should render_template('show') } }
  end

- where I have even had to wrap the stubbing, which is the core of Stubble, in my own method to get the compact testing style I like. I don’t think I use Stubble in the way it is intended, but I’d like to be able to simply wrap do my entire outer describe in the stubbing statement, this having the magical teaser variable available in all my tests, helper methods and before-statements. Also, I have not yet managed to mock or stub anything on the magical teaser variable, so if I for example want to verify that some method is called on teaser, I can’t use Stubble in that test. Again, to be fair, Stubble is in very early development, and I still need to learn about it, but if these two problems are solved, I think Stubble is going to ease a lot of my controller testing pain.

If you, dear reader, feel that you have a better, or simply different, mix of testing frameworks, I’d love a comment from you about your choices and reasons for going with one thing over the other.

Community Day 2009 in Copenhagen

Casper Fabricius — Sun, 31 May 2009 13:36:36 +0000

It has been a while since I had a good technical post on this blog, and this is will not be one either. Instead, just a few brief words on a very successful event for geeks in Copenhagen that took place last Thursday. Sponsored by Microsoft and co-presented by the Danish development community, Community Day 2009 Copenhagen delivered what it had promised: A day with free beer and food, interesting presentations and lots of networking across the usual technical boundaries. While the event, previously exclusively with a focus on Microsoft technology, was dominated by seasoned .NET developers, we, the Ruby crowd, was well represented as was the PHP programmers.

Daniel Mellgaard Frost, Developer Evangelist with Microsoft Denmark, had put together a diverse program where only two talks was devoted entirely to Microsoft technologies (Silverlight and LINQ), but six out of eight talks was about web development in some form. I did a talk on ActiveRecord, the O/RM of Ruby on Rails, and according to the many happy comment I got afterwards, it went pretty well.

One really great thing about Ruby is that you can start writing code in front a crowd that have never seen the language before, and they will understand everything you are doing – provided, of course, that they know another object-oriented programming language. Ruby is such a beautiful language that it instantly appeals to most coders, and that makes it a pure joy to do a presentation mostly based on live code examples such as I did.

It also helps that ActiveRecord has an impressive number of features to show off, and even though I don’t how much it really mattered, I think I made a good tactical choice in demonstrating the O/RM running against a Microsoft SQL Server instance. This post, by the way, is what helped me to get my Mac to talk to SQL Server, but bear in mind, that if you run an older Ruby version and/or use the installation that comes with Leopard, that tutorial will upgrade you to Ruby 1.8.7 running via Macports.

Here is the presentation slides from the talk (in Danish), and here is the very limited quantity of code I wrote.

I also lead an open space meeting on jQuery – the presentation on the topic was unfortunately canceled in the last minute – and although I am still learning the many aspects of this great Javascript framework, I think every web developer owe it to his or hers own productivity to take a look at it. Doing Javascript development with jQuery and Firebug is immensely effective, not least because of the literally thousands of open source plugins that have been written for the framework by the community.

Thanks for Daniel, Microsoft and the community sites for sponsoring and organizing this fun and inspiring event – I look forward to next year.

Notes and impressions from RailsConf 2009

Casper Fabricius — Fri, 08 May 2009 19:49:24 +0000

I’d never have guessed that the first time I’d visit Las Vegas, the gambling and the drinking, the shows and the shopping would be a minor thing, something that I’d squeeze in between what really mattered. But RailsConf 2009 had such a comprehensive and interesting program that this ended up being the case. From the casual networking at breakfast and lunch over packed keynotes and high-quality talks to late-night Birds Of a Feather sessions, RailsConf did give the attendants any reason to step out if the air-conditioned Hilton and into the sun and lights of the Strip.

We did that anyway, obviously, but mostly we were learning, tweeting, chatting, coding, emailing and taking notes at a conference where the wifi actually worked and power strips were easily available. I’m not going to reference all the talks that I went to here, but I have uploaded my notes here. Also, I’ve written a detailed summery of David Heinemeier Hansson’s keynote and a few select talks that I attended for RailsMagazine, ~~but the free PDF-edition won’t be available for another two weeks~~ now freely available for download … slides from all the presentations can be found here.

So what did I take away from RailsConf from the top of my head? The first that springs to mind, is that I got to try RubyMine, a new IDE for Ruby on Rails. At first glance this might look like another Aptana or Netbeans, but the Rails Envy guys gave a stunning demonstration of the power of this new IDE: From TextMate keymapping and navigation, over code completion and refactoring that actually works, to automatic diagramming of models and their relationships, this product looks like a real productivity booster. I’m going to try it out the minute I get home.

Rack kept popping up everywhere. Lots of talks on Rack and Rails Metal (which is really just a wrapper for a “raw” Rack handler), and now Rack suddenly doesn’t feel so scary anymore. It just a way to do cool things on a raw request and/or response without the (full) overhead of the Rails stack. JRuby was another popular topic, as well as clouds – how to deploy to server environment that will seamlessly scale with your needs.

I have been following IronRuby with great interest since the project was started 2-3 years ago, and I was a bit disappointed to hear that the .NET implementation of Ruby is still nowhere near completed. I asked Jimmy Schementi from the Microsoft IronRuby team what took them so long (to be honest, I was a bit rude, sorry Jimmy), and asked that things simply took time. He said that JRuby had been 6 years underway. The positive news, however, was that the IronRuby team is still very committed to making their implementation fully Ruby 1.8 compliant, and that are using Rails to measure their success against.

I’d love to tell you more, but my plane is leaving soon, so you will have to make do with my notes.

Introductions to Ruby on Rails

Casper Fabricius — Wed, 22 Apr 2009 07:45:03 +0000

You have at least two chances to get introduced to Ruby on Rails by yours truly this year. I do a presentation on Rails with a focus on ActiveRecord, the ORM of Rails, on Commity Day 2009 in Copenhagen. I am also teaching Rails used with agile methods at Copenhagen Business School this fall.

Community Day 2009 is free 1-day event May 28 in Copenhagen sponsored by Danish developer communities. Besides my two cents, it also features presentations on Android, Flex, Air, Silverlight, LINQ, Drupal, jQuery and ASP.NET MVC – in other words it looking to be a lot of buzzwords and popular technologies explained. As if that wasn’t enough, the day also include three geek-friendly meals, friendly competitions and lots of free beer.

The course I will be teaching at Copenhagen Business School is called Agile Development in Practice, and builds upon a theoretic platform of agile methods. The course focus is on giving the students practical experience with Scrum and Ruby on Rails through a combination of traditional teaching and working with real-life examples. The course is free to attend for all Danish students, and counts for either 7,5 or 15 ETCS points. Others can also enroll in the course for a fee. The course description is not yet available on the CBS homepage, but I will link to here as soon as it is ready.

But before all that, I myself will hopefully learn many new and useful things about Ruby, Rails and all things geeky at RailsConf in Las Vegas. See you there? :)

Uploading multiple files with progress indicator using jQuery, Flash and Rails

Casper Fabricius — Thu, 26 Mar 2009 14:15:37 +0000

I just implemented a new way of uploading assets such as photos and PDF-files to Lokalebasen.dk. There is nothing revolutionary about it, but I hit a few snags on the way, and I thought I’d share my choices here.

Lokalebasen (a Danish website for rental and sale of business property) is (of course) based on Ruby on Rails and uses the notoriously brilliant jQuery as Javascript framework. When the customer asked for a progress bar while uploading assets, I knew there was basically two choices: Polling the server for the progress of the upload, or uploading through Flash. I choose the last option because I believe it is easier to implement, and it gives the added bonus of being able to start the upload in an “ajaxy” way without refreshing the page.

Several ready-made solutions exists, and chose one that was built as a jQuery plugin, was updated recently and was easy to use while being highly configurable: Uploadify. This article is not an Uploadify tutorial – you’ll have to work the out from the documentation and the examples. Rather, it’s about the last piece of the puzzle, how to make Rails play nicely with Uploadify.

Lokalebasen uses attachment_fu for handling assets. Since traditional file upload was already implemented, I had fallback functionality for users without Javascript or Flash – and so should you. All I had to add the controller handling the upload was a detection of the correct content type. Browsers will usually provide this, but Flash does not. And so the controller ended up looking something like this:

The mime-types gem is used to detect the content type – installation and usage is explained here.

I needed the functionality several places, so I wrote a partial I could reuse:

There is a lot going here, so let’s take it from the top. The content_for :head section is the code that will be placed inside the part of the page – my layout takes care of that with a yield :head call. So first the Uploadify jQuery plugin javascript file is included, followed by some javascript that applies Uploadify to the file_uploader div seen later in the partial. This includes a lot options, some of which uses variables supplied to the partial. Here is an example of how I call the partial:



 I won’t walk you through all the options I supply for Uploadify, but let’s take a look at the important ones: script is where Uploadify will post the uploaded file to. This should be the create action of your asset controller. scriptData is the most tricky one. The option specifies what parameters should be posted to the controller along with the file. 'format': 'json' ensures that the wants.json block is invoked in the controller, instead of the default wants.html. This helps the controller to separate Flash uploads from ordinary uploads. The two other parameters in scriptData will be explained later in the article, is they are the key to get the uploading past security and authentication measures taken. fileDataName extracts the name to use for the uploaded file (e.g. asset[:uploaded_data] for attachment_fu) directly from the fallback form. onComplete makes an ajax get request through jQuery to the same url we are currently on. I use this to render some javascript that updates the page in a wants.js in the controller.
There are several gotchas when you upload files through Flash. The most common one, which also apply to ajax, is the infamous ActionController::InvalidAuthenticityToken exception. You will get this exception on any default Rails installation with authenticity checking enabled. Rails expects any post to an action the include the authenticity_token parameter. It is used to verify the post actually came from the same application, and Rails automatically adds to all the forms and ajax requests it generates. In this case, we have to apply it manually, and this what happens with 'authenticity_token': encodeURIComponent('<%= form_authenticity_token if protect_against_forgery? %>'). The form_authenticity_token returns a valid token, but first we check if forgery is enabled. If it is disabled (which it usually is in tests), we will get an error if we invoke form_authenticity_token.  encodeURIComponent makes sure that any characters in the token is encoded correctly. With this parameter, we should be able to make an authentic post through Flash – or maybe not …
Rails use data in the user session to authenticate requests, and requests directly from Flash does not include the session cookie that Rails use to find the session. Thus we still get the ActionController::InvalidAuthenticityToken exception, even with the authenticity_token parameter added. We have to make a slight hack into how Rails handles sessions to make this work. Place this code in a file in config/initializers to apply the hack, which tells Rails to try to read the session id from a parameter, if it can’t find in a cookie. This will only happen, however, if we add the line session :cookie_only => false, :only => :create to the asset controller. Also, we must supply the session in a parameter, which is what '<%= Rails.configuration.action_controller.session[:session_key]%>': '<%= u session.session_id %>' } do. The unique session key of the application is taken from the Rails configuration, and the session id is taken from session.
With these measures in place, Rails can now properly authenticate our Flash upload request as a legal, secure post. As an added bonus, actions protected behind session-based logins now also just works. And I would guess that most applications require their users to register and login before they can upload files.
Finally, here is a trick if you use http basic authentication e.g. for the administration tool like we do on Lokalebasen.dk. Place an is_admin? flag in the session, as shown in the code below. This will allow even Flash uploads to be authenticated, even if they don’t supply http basic authentication information:



Playing with Webby
Casper Fabricius — Sun, 15 Mar 2009 15:32:54 +0000
I have been in a relationship with Ruby on Rails for more than 3 years, and I’ve completely dedicated and faithful to the beautiful web framework for almost 2 years. Until now.
Today I decided to cheat on Rails. And I’m not talking going back to the ugly ex, ASP.NET, or getting back in touch with old flirts such as PHP or Java, no … Once you go Ruby, you don’t go back.
But there are other Ruby web frameworks than Rails. “What? I thougth Ruby was invented for Rails, as a kind of unintentional side effect?” you might say, but it is no so. Until recentl, Merb has probably been the most well-known “Ruby-based framework that is not Rails”, but now the two are getting hitched and as such we have to look elsewhere for alternative Ruby frameworks.
Webby is one such framework. Or to be fair, Webby is so much less than both Rails and Merb, and that’s the whole point. Webby are for simple, static home pages that can be hosted on anywhere. The Ruby framework generates static html files based on layouts and content pieces defined in the project. It doesn’t use a database, it doesn’t parse forms and that is exactly the simplicity you sometimes need.

The two greatest benefits in Webby is:

Content is plain text files and can be put in source control painlessly
Output is plain html files and be deployed anywhere with just FTP, RSync or SSH

As I see it, this makes Webby the perfect “un-CMS” for a web site maintained by developers. We don’t want to type in long texts in textareas in the browser – we want to do it Textmate or whatever our favorite text editor is called. We want full control over the HTML, we want speed and we want real versioning for our content.
Some times Rails is just plain overkill.
Resources:

Webby homepage
Great Webby tutorial (but a bit outdated, make sure to replace references to webby with webby-gen, and references to rake with webby.)
Another good tutorial


  



Reflections on Copenhagen Twestival
Casper Fabricius — Sat, 14 Feb 2009 23:29:59 +0000



© 2009 Rasmus Luckow

We were all there. The geeks, the journalists, the communication and new media consultants and the Internet entrepreneurs. Copenhagen Twestival was my first experience of meeting the Twitter community, and my guess is it was probably also the largest gathering of Danish Twitter users to date – we were around 120 people. Turns out that the Danish tweet-crowd consists of many well known faces from gatherings such as Copenhagen Ruby Brigade, Barcamp Copenhagen and Reboot.
Copenhagen Twestival was, along with many other similar meetings around the world, a charity event with the purpose of raising money for charity:water – an organization that argues that clean drinking water is the essential foundation upon which developing countries can evolve into something better. I can’t claim that I suffer from any great social conscience, but when Maame Agyeben – a former intern with the organization – told about charity:water, I was truly impressed. Their administration costs is sponsored separately, which makes them able to say that 100% of the general donations goes to building wells.
Red Cross and other global help organizations are doing a great job, but I like the prospects of charity organizations with a more narrow and dedicated purpose being able to pursue their cause globally by innovative use of Internet services. That night, we generated DKK 5,000 from the sale of 500 lottery tickets to win donated gifts, and probably a similar amount from buying overpriced, donated drinks.




© 2009 Rasmus Luckow

The twestival was not just about water and charity. Members of the Danish Twitter community had prepared presentations, and one of them was Mikkel Malmberg a.k.a. mikker with a talk about Twitter – for people who know Twitter. Mikkel was introduced as “the craziest guy on Twitter”, and he showed himself worthy of the title with an entertaining and energetic show. I wouldn’t do his talk any justice by repeating it in text – you will have to see him in person some other time.
The culmination of the evening was the Twitter panel, consisting of Henrik Fohns, journalist from DR, Thomas Madsen-Mygdal, entrepreneur and organizer of Reboot, and Troels Jørgensen, director of Berlingske Online. The format was a number of predefined questions – ideally in 140 characters or less – which each panel member got a chance to reply to. Fohns is a well-known voice from a long-running Danish radio series on technology – Harddisken – and it was good to see him in the flesh. It was also clear that this was a man with great experience in voicing his opinion on media and technology in comfortable, well-phrased sentences, and I for one felt compelled to believe in everything he said just from the familiarity of the voice.



© 2009 Rasmus Luckow

Another familiar voice was that of Mygdal. I know him from his Reboot opening speeches and from some of the many technology projects he is involved with, but I didn’t know how opinionated and loud-mouthed he could be once someone gave him a microphone and asked him to voice his opinions. He reminded me of the hero in the Ruby on Rails community – David Heinemeier Hansson – but where David’s battle is with “enterprise” software development, Thomas’ seems to be with established media and journalism.
The first question was about the future news outlook. Mygdal said that journalists does a poor job, because it is impossible to do what they do. Also that the business model for news papers hasn’t changed in 250 years, which why they are they are now in so much trouble. “It’s pure biology”, he said, “nobody tries anything [..] We are really fucked, but we have to try something and fail.” Fohns compared the volunteer news papers run by all kinds of unemployed people in the 80’s to today’s blogging. It is journalism by the unestablished, he said, and he called it “New Cultural Press”.



© 2009 Rasmus Luckow

Another question was: Do we even need the traditional media? Troels Jørgensen was of the opinion that journalists has far too high wages in Denmark, compared to Sweden, for instance, and that was one reason it is so hard and expensive to run a media house in 2009. Mygdal pointed out that we use the term “new media” every time something new comes along that we doesn’t quite understand. In the mid-90’s, the Internet was called “new media”. He said that we need to reinvent media in a way that really brings the new opportunities together, instead of just trying to coerce “new media” into “old media”.
One final question worth mentioning was on the issue of media subsidy. As Mygdal put it: “We spend 6 billion on media subsidy – the government could finance 2,000 micro medias at 3 million each a year for that money.” However, as Fohns objected, working in small units, you don’t always have the required impact. As an example he mentioned the case of IT Factory, where the freelancer Dorte Toft, who spearheaded the whole uncovering process, were under a lot of pressure from the lawyers of Stein Bagger. That kind of pressure is easier too handle when you are part of something bigger, and have lawyers and other support of your own to back you up.



© 2009 Kristoffer Solberg

I also remember that Mygdal mentioned at some point that Twitter really isn’t something new, that it is simply derived from blogging as a format better suited for people like himself, who might not be that good at formulating long articles. What do you think, perhaps I’d also be better off just keeping to 140 character outbursts? :)