Then you are developing sites and systems by yourself, then most of the time don’t have a good designer at hand. Some of us, just say f*ck it, and make some ugly site, and fools our self into thinking that people will use our stuff, it the core or idea is good enough.

Newsflash: No one uses ugly sites, so get into the habit of thinking a good design as a must have.

So how does a developer start to be a “phony/fake designer”? In this post I will outline some of the things, that I find that helps me design stuff that is “okay”:

1. Fonts does matter. If you are using Arial or Verdana for all of your fonts, you are missing out of a cheap way to make stuff look good. Take a look at Google Fonts and start thinking about your font usage. Using a custom font for a headline and such, can make stuff dramatically more interesting.

2. Think about readability. Can people easily read the stuff on your screen? Most of the time developers tend to use a too small font size. I don’t have any hard rules here, but try to think about that people that is using your site, may use a smaller screen than you. And think about contrast, as they may be in powersave mode, or have a very dark screen.

3. Find good icons. You can find alot of good ones using IconFinder.com

4. Use images, to make stuff more interesting. A quick google image search, and make a boring site a little more attractive.

5. Steal steal steal. This is the most important point. You need inspiration. Look at sites you use. Search for sites with good design on google. Look at their CSS, look at the page structure. Are you creating a blog? Then look at other blogs! Also, get into the habit of bookmarking cool websites, as you browse the way in your day-to-day surfing.

What helps you, when you need to design a website, as a developer?

This neat little trick enables DirectWrite in Sublime Text 2 on Windows, and makes the font rendering way better

Twitter Bootstrap hits 2.0 - adding cleaner HTML and responsive design.

Som en af folkene bag Odense .NET User Group, bliver jeg tit spurgt om hvad der sker rundt omkring, og om der er noget man skal deltage i, eller et møde/event omkring et fedt emne i en af brugergrupperne. Endtil nu må jeg indrømme at jeg ikke engang selv har haft det store overblik over hvilke møder eller arrangementer som sker rundt omkring i Danmark. Så svaret har fra mig tit været, at den pågældende person kunne gå ind på de forskellige brugergrupper, og se hvad de tilbyder. Men problemet med dette er, at mange f.eks. ikke har en RSS-Reader, eller at folk bare ikke har tilmeldt sig de forskellige RSS feeds, da de meget sjældent er intereseret i alle møder, som den pågældende gruppe/virksomhed tilbyder, men engang imellem kommer der emner, som man gerne vil rejse langt for at høre. Derfor skal de huske at gå ind på en masse hjemmesider, for at danne sig deres overblik.

Så selvom det rent teknisk er enkelt at vide alt hvad der sker i det danske udvikler community, så kræver det en masse research og at man finder sig i en masse støj iform af ting som ikke interesere en.

Geekhub.dk er begyndelsen på løsningen på dette lille problem. Ideen er ganske simpel: Vi lister simpelthen alle events rundt om i Danmark, som er interesante for udviklere.

Vi ved jo alle at lave sådan en hjemmeside ikke er den store bedrift, og er stort set bare noget CRUD oven på en enkelt database tabel. (Det tog mig nok en eftermiddag at lave den, og den har udgangspunkt i en Scaffold i et Ruby on Rails projekt.)

Men det store arbejde i sådan en hjemmeside, er at sørge for at det er det bedste sted at gå hen, for at få et overblik over hvilke events der kommer. Dette kræver lidt manuelt arbejde, og består i sin enkelthed i, at jeg abonnonere på en masse RSS-feeds, og piller de events ud som kommer der. Udover dette kan alle foreslå et event, hvis det mangler på listen. Det har f.eks. Trifork benyttet sig af, da deres geek-nights manglede på listen.

Geekhub.dk er på ingen måde færdig, og jeg sidder og arbejder på den i min fritid. Derfor er der en del skarpe hjørner, men igen, så er det vigtigste den data som siden repræsentere.

Så tjek den ud, på geekhub.dk. Hvis der er et møde som mangler, så brug "Foreslå et event" i toppen af menuen. Hvis der er noget funktionelt du ønsker implementeret, så brug Feedback knappen i venstre side.

Hvis du har lyst til at læse koden under geekhub, eller har lyst til at hjælpe, så er projektet tilgængeligt på github

Håber det falder i god jord, og at folk kan bruge siden. Husk at der også er et RSS feed, hvis du gerne vil have besked, når der kommer nyt på listen.

The problem about Web Storage, is that it's really just a key/value pair dictionary, that can only contain string values. It's very simple to use:

One thing to note, is that the data is shared across a origin. So watch out if you have multiple HTML5 apps, that they don't overwrite each other. Also note that there is a max of data you can store. This are independent of the browser the user uses. (typical 5mb, but it is a user setting, so you never know)

Anyway, to store complex objects, the trick is simply to convert your object to json:

Be awesome - write more JS :)

I've tried to make it compatible with smartphones as well. It works on iOS and Andriod systems, but the size of the components are not so finger friendly yet.

So check out this simple app here: tudoo.deldy.dk - read the code comments and steal all the code on github.

Many have already solved these issues like SquishIt. But with the recent release of Rails 3.1, the ruby people have yet again found a better way to solve the problem.

So why not steal the idea, and implement in .NET?

I give you AcidPipe. It's my take on the Rails 3.1 Asset Pipeline.

Watch this lille demostration, about what it can do:

Remember that this is a early alpha preview, and is not yet ready for production sites.

Download Acid Pipe Alpha 1 here

Check out Twitter Bootstrap

Let's get some things clear:

• DB testing is fast enough
• Integration Tests sometimes gives more meaning that one million unit tests.
• If you don't test the database at all, then you leave out a important part of your app.

To make DB testing work, there is really one big problem: Creating the test database, and keeping it up to date. Luckly it don't really take much to create it, and be able to keep it up to date. The simplest thing is to use this little bat file:

It requires that the source and destinations databases exist. The database names are case sentitive. I recommend to have the test database on your local machine (.\sqlexpress). Sometimes foreign keys is in your way, look here on a SQL script to remove them. Run that script after schema.sql

Then simply run the bat file whenever your schema has changed.

Now you are ready to test using your test database:

• First off. Remember to switch the connectionstring to the test database :)
• It's important to create your test in a transaction, and then make a rollback after each test. Use either the TransactionScope object, or look for a RollbackAttribute for your favourite testing framework. This is the key to making DB testing work, as your DB then always is in a consistent state

That's it! You are now ready to journey though the world of testing with a database. It makes testing your application alot easier.

So whats wrong by using this form of "chunking", your data? It's simply wrong because it's overused. Sure paging can have some merit, but we used paging so long, that we are just not thinking about how we use it anymore. Who really thinks, that if you show more than 10 items in a list, that it's going to be slow? No one - but we are still making the smallest pagesize as the default. So we give the customers a way to small page size to work with, and also ask them to hit a very small forward link at the bottom. That don't make finding of data a breeze: I need to scroll (normal users move the mouse to the scrollbar), then position the mouse the right place and then click. Thats tedious, and just not a good user experience.
Give you user a page size of 10, then I can assure you that most normal users never gets to the end of the list.

Lists normally has two usecases:

• Finding the one item that you want, while knowing something about it. Aka. searching.
• Finding a interesting item, like a news story, or a product you did not knew you needed. Aka. browsing.

Searching

So first off. If you users are using your list for finding the item, and they is actually using the paging-facility, then there is room for improvement. Make a good searching instead, so they can search, and then the right product or item will be on the first page, preferably the first item. Help them with autocomplete, and suggestions at much as you can, to help them not reach the dreaded "No results" page. But one rule to note here: Don't show them fake results, to ensure no empty list, thats a bad practice, that makes your users think that your search is broken

Browsing

If you like your users to browse, make it a nice and easy. Continuous Scrolling is the key here. Most of the time, you can actually have quite a big list on one page, without suffering much performance. If you have images, then load them only if the users scroll down to them. (There's javascript plugins for that) If you really want fast performance, then load a small list first, like maybe 50-100 items, and then on when the users reaches the bottom, load a longer list, of lets say 500 items. The user should not see any separation of the first and second page of items. Thats the logic behind infinite scrolling. From the users perspective, this just "works", and is a joy to use. The user will see more products, and if you are lucky, they will discover more items, buy extra, and come back.

Filters

If you are having a list of over 100 items, or so. Look for a way for the user to filter the items. You can use a traditional filter by brand, or category, by using a filter section at the top. But that really comes with it own set of issues sometimes. If your customer is really browsing, then they many times want to look at more brands, or more categories. Also they may not even know what category there product is in. Think about displaying what filters a product is in (think tagging), and make it easy for customers to change the filter to match one or more tags, like: 'Kitchen knifes', or 'Gift ideas for males'

Instead of making the customer decide up front, we are allowing them to change their filter mid-list, when they find something interesting. If you need some extra filters, then try not to position them at the top or bottom of the list, place it at the left or right hand side, and make it a always-visible panel, or make the top "follow-along" when you scroll down. When the list is long, then it is just tedious to scroll all the way to the top, to change the filters, so avoid that.

Sorting

The same goes for sorting as for filters. It is tedious to move to the top of the list to change a sort order. Have it at a always-visible panel, if possible. Think about if you really need sorting, and what sorting you really need. Most of the times users want to see even see the most popular products or the cheapest. Sorting by clicking columns is rarely a good practice. Most of the time, you need to click that thing twice, and it just becomes weird if you need multi column sorting. Most of the time, a set of links works just fine.

Recap

This ended up being a long post. To make myself clear, then this is just my personal opinion. I don't have any data backing my statements. But I hope that you can agree with me, that you need to think about the usecases and useablity of your lists, and that paging is just not always the best idea.

All this cloud talk, is about to rock your hobby-world. Because cloud can bring hosting cost down, and because all the providers all wants a big userbase, then a lot of them is offering a free plan.

Here is a list of tools I use, to my hobby projects. I'm paying under a dollar a year, for hosting all my hobby projects. If something grows to be cool, then all these tools also offer possibility to scale - or a price off cause :)

I've only included products that don't have a 'time-limit' - like 3 months free. These products has a completely free time-unlimited plan, or a very low cost for usage.

Heroku and AppHarbor

Heroku is the place to host Ruby or Node.js apps. They offer the coolest way to deploy, that I have ever seen. Just push it with git! This is so cool, that the people over at AppHarbor have done the same for .NET apps.
Heroku offers one "dyno", and a 5mb database. 5mb don't sound like much, but it's not a hard-limit, and the 5mb is only the raw data size. Over at AppHarbor, they are offering the same, but with a 20mb database.
You need to check either Heroku or AppHarbor out, if you do Ruby or .NET programming. This blog is hosted on AppHarbor on their free plan.

PostMark

Postmark is email sending as a service. Get the first 1000 mails free. They offer a good and easy API, and integration to both .NET and Ruby is very easy. They even help you set up your domain, so your email don't get in the users spam folder. Need more than 1000 mails? 1000 more mails cost 1.5 dollars. This blog is also using PostMark, for sending me a email, when a new comment is created.

IndexTank

This is one of the things, that I found by looking at the Heroku Add-on list. This is search as a service, that will help you make an awesome search feature for free. You get up to 100,000 documents for free, and up to three indexes. It's very easy to get working with Ruby, but they don't have a .NET library just yet - so make your own :)

Amazon S3

This is not really free, but very cheap for limited use. Amazon S3 lets you store files in the cloud. If you store a gig, then the cost will be about 1 dollar a year, and you are properly storing less. This blog uses S3 for images and so on.

Do you have any cool products to the list? I have only included the ones I've tried. If you are looking for more, then take a look at the Heroku add-on list or the AppHarbor add-on list

Just like I don't trust the person to agrees 100% with a political party, I don't trust a person who don't know two programming languages, or thinks that their programming language is the new tool of gods.

C#/VB.NET/.NET is far from perfect. So is Ruby or Rails by the way. .NET is an awsome platform, but unless you know something other than one thing, you are really a capture of that technology.

You only think solutions in .NET, using the .NET way, if you only know .NET. I think solutions much simpler after I learned Ruby. Not because Ruby is a language that is dynamic, and by that ways loses much of the needs for big architecture stuff. But because, when you are on deep water on Topic X, you really starts to think like you really should: 'How can I get this thing to work?'. Instead of the normal 'How I can make Hello World fly to the moon?'

So learn some other stuff. Build in a different language at home, than you do at work. Don't be afraid of the notorious ".NET only fanboys". In my experience, as a founder of a user group, is that they don't really exist - and if they do, shame on them - not you!

The first place to go, is definitely "Rails for Zombies":

• railsforzombies.org - it's a nice interactive tutorial that lets to experience rails without installing anything - it's just right in your browser.

When you are dont with the tutorial, then the road splits. Each person are different, and each have a different need to understand how things work before using it.

If you are one of the persons that wants to understand and know the Ruby-language syntax, then first complete the:

• rubykoans.com - it's a nice lille directory of small tests that helps you understand Ruby. To use it, it's just a matter of installing Ruby (if you are on a Mac, you even got that already), and then a good editor. TextMate is the original favourite of Rails developers (on macs), but for basic Ruby, then a basic editor will also work.

After you completed the koans, (or just skipped them), then take a look at this e-book:

• Agile Web Development with Rails (4th edition) - first off, be sure to get the right version. The 4th is the newest right now. But if there is a newer one, then take that! This book helps you learn rails by building a quite cool little book shop.
• An alternative to a book is also the TekPub series on Ruby on Rails. There is two series one on Rails 2, and one on Rails 3. They quickly becomes very advanced, and is not very hands on, so I still prefer the book over these ones - but if you a a video kind of guy/gal, then these is still a great buy.

When you have looked at all of above, then be sure to take a look at:

• railscasts.com - the most awesome (free) tutorial site - ever. This dude releases new stuff every week. Each one takes about 10 minutes, and gets you into stuff quickly. Search or browse for a topic, and take a watch. And after that subscribe to it with iTunes or other podcast software.
• peepcode.com - Want to have a more in-depth screencast of Topic-X? Then look if peepcode has it. All there screencasts is superb quality - the pricing is not bad either.

In the .NET realm, we are known to be very good at being backward compatible. Many times, to much in fact. We focus so much on backward compatibility, that frameworks becomes rigid to use, and we need alot of configuration, just to get the new stuff.

ASP.NET is a perfect exsample. In the first versions of ASP.NET the web.config went from being a good slim file, to be a massive monster of weird configuration, and assembly binding. Sure, they moved some of it away from web.config in .NET 4, but its still somewhere in a config file hidden in your .NET Framework.

When moved out, its not really a "problem" for the users, but I bet it's a problem for the maintainers of the ASP.NET codebase. It marks a filosofi: "We want to make it as seamlessly as porsible to upgrade", but it also states that it will make it "More problematic for new projects". Just look at ASP.NET MVC 3. They just removed all the noise, from the web.config in .NET 4, and now ASP.NET MVC found a lot of other weird stuff to put in there - and they even introduced another one for razor. Nicely done!

I love ASP.NET MVC, don't get me wrong. But I don't love the .NET nature of making upgrading easy, by making the new projects pay. You are also making the framework more fat, and in that way punishing the developers of the framework, and the users that must understand the framework. Before you know it, it's all bug-fixing - new features that can't be implemented because it will break backwards-compatibility, and very long development cycles. It looks like it's already happening to the ASP.NET MVC. And it’s sure that been that for a while, for the ASP.NET Webforms crowd.

So to look for a solution, we do, as we offen do these days: We look at the Ruby community.

When looking at Ruby on Rails for example, they remove things all the time. If it's not optimal, or becomming a hazzel, they get rid of it. But instead of just deleting the file from the project, they instead refactor it out into a Gem (for .NET peeps: Thats what nuggets is based on), and make the community support it. Because many ruby people actually take it as a normal thing to submit and support open source libraries, if they use it, then this method actually works. It makes the developers of the core framework more agile, and make them focus on the 90% of the developers need.

That means, that when a new version of rails is released, it may mark some things stuff deprecated. It then tells you, that this will be removed from versions later than X-date, and tells you a solution. Offen this is to include a gem (that’s one line of config: gem ‘x’), that adds the feature back in.

What that so hard? Surely people that are upgrading, reads the upgrade docs, on what to do, so let’s put the work on their shoulders - it's not really a lot of work, but instead of putting all that enable statements in the web.config to enable, a new needed features, then instead make them put in a disable configuration instead. Take bad stuff out, and let better solutions come in. But don't just remove support. Move it to the community, making the last users, of the thing in charge.

Believe me, it's an important practice, that must be applied to any work of a framework you use, even your company’s internal framework. Move old stuff into nuggets, dlls or gems, and make the core clean, fast, easy to maintain, and not a library that developers fear to touch, because: "There be dragons"

So when thinking backward compatibility, make it reserve of what you normally do - don't make the few users of the old, block for the new. I really hope that this will happen with ASP.NET MVC. Fingers crossed.