A while ago I recorded a show with the Distributed Systems Podcast gang. It is now available online.
I think it is pretty interesting one, since it touches on quite a lot of aspects. RavenDB, how it is built, how you should approach building a product and a framework.
You can listen to it here:
http://distributedpodcast.com/2011/episode-007-interview-with-ayende-rahien
I am getting married on the 29th May, which is just a week away. You may notice a decline in the number of posts to this blog (and general activity for work related stuff) around that time frame.
For quite some time, I had to… endure certain types of jokes about what would happen when I would get married. Given the choice between my own happiness and the desires of some members of the development community to see me in a dark room eating pizza and working at all hours, I know what I would take… 
Never the less, as a consolation prize to those people, and as a way to spread my happiness, the following coupon code with give you 29% discount for all the profilers (NH Prof, EF Prof, L2S Prof, LLBLGen Prof, Hibernate Prof): WDG-45K2D467C5
The coupon works for single license purchases, and it is only valid until the 1st of June.
One of the more interesting aspects of Raccoon Blog is that we have done absolutely no performance work on the blog at all. Nevertheless, one of the most common items of feedback was that it feels much faster.
There are actually two reasons for that. The first is that unlike relational databases, we model the data so loading each page is usually just a single query to the database. The second is that RavenDB has been designed to be very cache friendly.
Think about this, if you are using something like Entity Framework or Linq to Sql , you are basically out on your own with regards to a caching solution. With NHibernate, there is a builtin option, but that one is:
In contrast to that, with RavenDB, caching is such an basic part of the system that we made it the default. Everything is cached by default (actually, we have multiple levels of caching, both on the client and on the server, but that is beside the point). The end result is that for the vast majority of cases, we only need to check if we are up to date, and all the data is already in the local cache.
I built this feature just for this scenario, but because it is on by default, I never actually thought about this, we just worked as we normally would, focusing on features, and RavenDB took care of the performance.
The new blog is up, and it has all been relatively painless. One thing that I learned, I can centralize servers and drop one of my machines, because it seems like I am using a lot less resources 
, I might even do that tomorrow.
I thought that it would be fun to detail how it worked using feedback from twitter. In timeline order, here are the the tweets and my responses…
Yes, it is a real blog. Theme support isn’t something that I actually care about, so it is mostly CSS if you want to switch between stuff, but it is all there, and quite simple to figure out.
That was during the update process, I disabled comments on the old blog.
Success! We aimed to give you the exact same feeling, externally. There are a lot of good stuff that are there, of course, but I’ll touch them later.
We actually never had search , but we will do some form of search soon, yes. RavenDB integrates very seamless, and the code is beautiful to work with.
Yes, it actually counted the root url, not the post url. Was actually surprising complicated to solve, because I run into a problem with string vs. MvcHtmlString that caused me some confusion. I understand why, it just brings back bad memories of C++ and std::string , cstr BSTR, etc.
Working with RavenDB is a pleasure, and I try to avoid RDBMS if I can.
That was the goal
Yes, we worked hard to ensure that there are no broken links, and I even think we managed to get it right.
Never thought to do so, but a great idea, implemented.
Agreed, that would be a good idea, go right ahead: https://github.com/ayende/RaccoonBlog/
Happy to hear it.
I tend to fix minor stuff, there now.
Success
Indeed…
ASP.Net MVC3 for the UI, and some very minimal infrastructure.
I sense a theme here…
Yes, we use different ids for the RSS, so that caused a lot of ids to show up, but it is a one time thing, and it wasn’t work the effort to maintain ids.
Um, what are you doing in this post?
Sparse is one way of putting it, it is a lot closer to non existing. We probably will create some sort of system tests, but I don’t see a lot of value in those sort of tests, mostly because most of the code is basically user interface, and that is usually hard to test.
Forgot to add the appropriate CSS there, I fixed that. And I had an issue with desc/ asc ordering for the next/prev posts. Fixed now, thanks.
Overall, I am very happy about the new blog engine.
Originally posted at 5/12/2011
Since I am removing the ayende.com site (in favor of this blog), I’m using this post to note where you can still download the Hibernating Rhinos webcasts.
One of the things that people kept bugging me about is that I am not building applications any longer, another annoyance was with my current setup using this blog.
Basically, my own usage pattern is quite different than most people. I tend to post to the blog in batches, usually of five or ten blog posts in a short amount of time. That means that future posts are pretty important to me, and that scheduling posts is something that I care deeply about. I managed to hack Subtext to do my bidding in that regard, but it was never perfect, and re-scheduling posts was always a pain in the ass.
Then there is RavenDB, and my desire to run on it…
What this means, in short, is that we now have the Raccoon Blog, which is a blog application suited specifically for my own needs, running on MVC 3 and with a RavenDB backend.
By the time you read it, it will already be running our company blog and it is scheduled to run ayende.com/blog this week.
What is Raccoon Blog?
It is a blog application running on top of RavenDB store and tailored specifically for our needs.
And just for fun:
Following my post yesterday, I decided that for now, we will have the following system:
On push, we will simply call git pull in the website directory. We use git ignores for the logs & data files, but that is about it.
It is primitive in the extreme, and it likely have many failure scenarios, but for now, it works. And very nicely, too.
Basically, I currently have a very simple procedure for deploying software, it is called: git push, and I really want to be able to do that for my web applications as well.
I know that Rob Conery has talked about this in the past:
And I know about Heroku and AppHarbor, that isn’t what I am talking about.
On my own server, I have a set of web application that I want to be able to update using git push.
Requirements:
I specifically don’t care about actually building the code, I am perfectly fine with pushing binaries to the git repository.
At first I thought about simply making the site a git repository and just push there. But you can’t push to non bare repositories by default (and rightly so). When I gave it some more thought, I realized that there are more reasons to want to avoid that.
Any thoughts? Any existing solutions?
Originally posted at 5/5/2011
The last time that I updated ayende.com was 2009, and I don’t see a lot of value in keeping it there. I am considering doing something drastic about that, and simply moving the blog to ayende.com.
Do you have anything there that you really care about?
Just to be clear, the blog will still be here, we are talking about the site available at ayende.com, not ayende.com/blog.
There are posts all the way to Dec 02, 2024
| Main feed | |
| Comments feed |
+972 52-548-6969
