Tuesday, November 08, 2011

Windows Azure - introduction

Recently I have made myself to do some work and start exploring the unexplored. First target that I chose was Windows Azure - Microsoft's cloud services platform. So here are my thoughts and first impressions about it.

First thing you must to do is creating an account in Microsoft Online Services Customer Portal: https://mocp.microsoftonline.com/. As a Microsoft client you must purchase a subscription for Windows Azure services. For all new clients there is a trial period in which we can test Windows Azure for free - it's very good option for start. We can just try it for ourselves.

When we have access we can sign in to Management Portal on http://azure.com. From there we can manage all our Windows Azure services, check what is going on and how our application is working. We can create dabase servers, compute workers, etc. in just few clicks, just choosing where we want to place our servers and after a while everything is up and ready to deploy our aplication. These all informations are presented by responsive web interface.  My first impression was very good - it's very intuitive in my opinion and it's first web page using Silverlight which does not makes me angry. Who knows better how to use Silverlight properly better than Microsoft? Good for them, for now.

But to do something smart and not pay too much we need to know something more about Windows Azure and generally what cloud services are? According to Microsoft:
Microsoft thinks of the cloud as simply an approach to computing that enables applications to be delivered at scale for a variety of workloads and client devices.
I can agree with that mostly but I think there is something more about cloud computing rather than just simply scaling mechanism - using the cloud of course gives us an opportunity to face lots of computings but this approach would not have it's name without using very large number of computers and treat them like one big powerful one.

There are few business models of cloud services:



IaaS was one of the first approaches used by Amazon Web Services Elastic Cloud Compute (EC2). We don't have to worry about Networking, Storage, Servers and Virtualization but still we have to consider things like Operating Systems, Middleware, etc.

PaaS is best fit for Windows Azure - all we need to worry about are our applications and data. It simplifies our tasks and helps us concentrate on our product.

SaaS is another more abstract level of managing our business - all we want is delivered to us as a service and we don't have to worry about anything - we are all using SaaS and often doesn't even realize it - Google has many services which are being delivered to us as a service (Gmail, Calendar, etc.)



Ok, so now when we know something about what cloud computing is let's get back to how Microsoft tries to approach it.

Windows Azure Platform consists of three main components:
  • Windows Azure
  • SQL Azure
  • Windows Azure AppFabric
These three main parts are the core of Windows Azure. So let's have a closer look on every one of them.

Windows Azure component includes three subcomponents:
  • Compute (responsible for doing heavy work)
  • Storage (not database, just simple storage)
  • Virtual Network (connects them with each other)
SQL Azure is just cloud evolved SQL Server with minor differences:
  • Database (relational database, compatible with SQL Server)
  • Reporting (similar to normal Reporting Services)
  • Data Sync (synchronization)
AppFabric:
  • Service Bus (general purpose application bus, available on internet scale)
  • Access Control (rules-driven access control for cloud applications)
  • Caching (general purpose distributed cache mechanism)
As we can see Windows Azure Platform consists of several loosely connected services which we can use. From these tools we can build our applications very fast.

The core functionality is Compute of course, in which we can use any other non Microsoft technology (Java, PHP and almost everything). Last but not least is that we can migrate our existing solutions to cloud in few simple steps and for example make our web application work on several distributed instances. We can also migrate our existing databases to the cloud - we can use SQL Azure just like normal SQL Server.

So to sum up Windows Azure is very easy way to build scalable network applications. All we have to worry about is our application, our idea and we can focus only on our product.

Friday, September 02, 2011

ASP.NET MVC3 - Razor view engine

Recently I've started working with ASP.NET MVC3 - I had some break from working with .NET. My first impression when looking at new project was - hey where are controls known from aspx pages? I've used to work with them some time later, but now files have strange .cshtml extensions?
ASP.NET MVC3 come with new default viewing engine - Razor - a very nice engine I must say. Its syntax is very easy to remember and generally is very intuitive and lightweight.
Some examples:
Hello @ViewBag.UserName
As you see there is nothing such as closing tag. We only write '@' and that's all. Now have a look at the for loop:
@foreach (var element in Model)
{
<p>@element</p>
}
Mixing HTML and Razor is very unobtrusive. If we want to do some code inside view (bad practice) we can just type:

@{
   string text="Hello";
   text+=" World";
}
Our layout page can look as follows:
<html>
   <head>
        <title>Title of our page</title>
   </head>
<body>
  <div>Common part of all pages</div>
  <div>@RenderBody()</div>
</body>
</html>

Writing own view helpers is also very easy:

@helper MyHelper(string text)
{
<p>@text</p>
}
Razor have some small disadvantages - we can't use big collection of prepared controls - but we can have ASPX and Razor views in one project - so there's no problem at all. When using Razor we now have better control over generated HTML. Better looking code, and views - Razor it's really worth using. As I said earlier Razor doesn't allow us to use .NET controls in it, we also can't use designer view in creating views - but we have something in exchange - the very good set of prepared helpers hidden it @Html.
We have helpers for creating forms, form inputs, links to another actions, to render another views or actions inside current view. For example this is the code responsible of viewing form input and validation message for it:
@Html.EditorFor(model => model.Name)
@Html.ValidationMessageFor(model => model.Name)  

Whe talking about Razor I can't ommit the @model keyword - which is very helpful. We can create strongly typed views - so view can only display one model class. So in action we write:
return View(modelToRender);
And in the beginning of the view we put something like this
@model OurNamespace.TypeOfOurClassToRender
From now on this view takes only instances of this class to render. To use this instance inside a view we just type:
@Model.someProperty
Take a good look, because there a difference in these keywords - one starts with upper case "M", and it's very important difference.
So I can say that Razor is very kind to work with. If you are not sure about using Razor in your projects don't hesitate to try it - you're going to love it for its simplicity and ease of use.

Thursday, August 25, 2011

Worse is better

Recently I've came across lot of development problems which every developer is finding is his or her normal work. Every time I was facing any design problem I'd had two options. First option - design it in a good way, taking in account future development of this software. In opposite we always can write something in a rude bad way, but few times faster.

And I have to say that it's very difficult question which way choose - because we will be doing something that nobody can ever see inside (I'm not counting any future developers of our system). So if it's worth doing it at our's best? Yes indeed it's worth spending some time if we'll be developing our system for couple of years, but if something is working identically why not to choose the shortest way to do it?

I'll be punished for what I say... take an MVC architecture for example. It's common knowledge what is it for - to separate model classes from views and from logic. The main reason of this separation is to keep eventually changes simple - and I agree with it, but come on - do you know anybody who ever switched to another database in project? Or changed view / templating engine? It's rather rare situation but now everybody wants to have this possibility. I think it's mostly to being cool. We can say - oh I can switch my db to another one and my website will still be working! In the meantime this website could be doing much more efficiently. Because if we are on some abstract level to be compatible with every db solution we're just loosing advantages which are given to us from the very specific db engine for example. Because if we use some specific options from one db engine changing it to another one is again more complicated. And we're in the same point with code that is rather blocking us but in fact we've chosen it to not being blocked by anything.

It's very funny in my opinion, and we should always consider our choices before we can start. And I don't blame MVC pattern - it's the best pattern to build websites and such. Only thing I blame is bad software management and bad planning.

So returning to the main point it's not always worth to do something the best possible way - it's rather to sustain project requirements as fast as possible. Because from the business point it's better to deliver something fast rather than working with something for couple of years and deliver the same product little easier to develop in future - if our competition deliver something earlier future development of our idea won't even exist.

So my point is if we're doing something - I don't know a website or even a desktop software we must focus on our requirements, and not doing something the best possible way. But in the other hand we must be careful enough and try to deliver solution that is fullfilling our all requirements.

So good requirements and good business plan is everything we need to deliver best IT solutions.

Friday, August 12, 2011

How to become a good programmer

Being a programmer isn't very easy. Of course learning one programming language is easy, but mastering it real good takes a lot of time and lot of problems to solve in that specific language. Learning next language if it is in the same paradigm is easier than the first one and so on.

If somebody is intelligent enough he or she could learn any new technology and any new language. It only takes time. I don't say that finding free time when you're working and / or studying at the same time is easy, but in our job we must learn at all the time. Languages, frameworks and patterns are evolving still.

If it comes to design patterns here it's identical situation - the only thing that matters is using them in practice. Only when we are doing something we encounter real life problems and we can solve them. Year by year problems to solve are much harder and harder. People are still searching solutions for the more difficult ones.

People say that good developer is when he tend to stay in deadlines. But in my opinion being a good programmer is being curious of how it's done inside in application. Because only if we knew what will be in memory and what computer must do if we do A or if we do B we can write effective applications. I know that when it comes to business time is very important, but for the cost of doing something well.

I've worked in company (I will not say name) in which everything was done in two ways:
- as fast as we can but doing dirty code
- as long as we could reapairing this dirty code made earlier
After some time I've noticed that 90% of programmers time can be spared bo doing something well once. So doing something well should be our goal from the start.

Todays languages are making programming lot easier - we don't need to worry about memory consuming and heavy weight of application. People will buy faster machines and / or client will buy bigger server - it's just not our problem they say.

Computer games today are being made using graphic tools and only a few scripts (of course there are some exceptions). If we look at demoscene we could find really cool graphics and really cool stuff which will run faster and look much better than games we can buy.

The difference is huge - the demos are from 4KB to 64 KB size only. And they look very nice and produce the best graphics possible at good performance - how could that happen? Because these small apps weren't done in stress of time and money - they were done by people who really enjoys what they are doing.

So in my opinion we should do something interesting for us or quit and find another job. Because only if we are doing something which is fun for us we would do it with enough passion and curiosity needed to do it well.

Thursday, August 11, 2011

Javascript: The Good Parts

In my projects I've encountered many problem involving doing something in JavaScript. First when I've came to problem when I needeed to use it I've searched the internet and found jQuery - which is very helpful. I copied it and it works! Really simple!

But later when I've stucked with some unknown for me problem and nobody could help me with that I've realized something is wrong. I knew really well object programming but here with this strange syntax I was helpless. Then I found this book:

http://www.amazon.com/exec/obidos/ASIN/0596517742/helion-20

http://helion.pl/ksiazki/javascript-mocne-strony-douglas-crockford,jscmoc.htm

When I read the table of contents I realized what I was missing. After reading it I can now say that I understand what really JS is. Author definetely described solutions for my problems - and now it was clear for me what I was misunderstanding.

In all languages we can always solve one problem in multiple ways - it's up to us which way we preffer, but some ways are easier to do than others and some ways just produce cleaner code. JavaScript is a language in which beginner with experience from other objectives languages can do a huge amount of mistakes. Programming in JS is very tricky, but also very fun. You must ensure yourself that you're really know what you're doing and what's happening in the code before doing something real big.

Author explains typical anti-patterns and shows what dangers are waiting for us if we do something wrong.

So now, after reading this book and several talks with smarter than me I can say that there are very few people who know this language very good - but it's a shame, because I see some perspectives in it. Its popularity is growing really fast in the dev community.

To sum up I recommend this book to every developer.

Thursday, July 14, 2011

Developers salary

As a developer I'm always searching for jobs offers on the Internet. I'm always wondering how much they can pay me for this position? Here, in Poland talking about salary in job is taboo. There are only few offers in IT which we can see salary before we go to the conversation.

It is rather strange and many of Polish companies are abusing this fact - I've been on countless interviews, wasted huge amount of time to get there, to obtain some information about company, etc. only to hear that they can give me only about half of my financial expectations.

I must say that I'm disappointed about that. Many of my friends from University or from my few past jobs are working for very small salaries according to what they can.

I think that in Poland we must wait couple of years to catch up to other bigger coutries in this topic. In my opinion on every job offer should be information about salary (it could be with some margins). It would spare everybody some time.

According to that I've googled some about developers salaries and I've found interesting article - "How much should you pay developers?".
http://blog.stackoverflow.com/2011/07/how-much-should-you-pay-developers/
Author of it says about few principles about financing development team.

Firstly algorithm is giving points in few categories. Each point is worth some money - there are no margins - it must be clear and fair for everybody.

Secondly another principle (my favourite) is transparency. Everybody knows how much others are earning and knows why - it can clarify what we need to do to earn more - and there is no situation that I'm not satisfied because of my colleague who is earning more than I but he has less experience. It is clear for everybody and team can even talk about their salaries in public.

Another principle is competetive - if we'll know that in company X we can acquire twice more for doing the same it's obvious that we'll quit our current job to take another. But if we don't know we can stay there for life. Companies should use this information.

In Poland many companies are very greedy. I've met and I'm still meeting managers who are searching for IT specialist with minimum 3 years of experience and offering them salary of a shop assistant. It's sad even more if we realize there are some people who will agree working for them.

So to sum up my point is that there should be information about salary on every job offer and we should always check if this salary is fair for this position.

Sunday, July 03, 2011

SEO

Some time ago I've been searching for book which would help me ta master techniques of SEO and SEM.

First I was trying to find some articles in the Internet but there were only single publications about it loosely connected with each other. Then I found interesting book - bestseller about SEO - "SEO Warrior".

I was kind of person that was thinking that all this SEO stuff was something we could do and forget about it. And I was really wrong... In fact the most important thing on our site is the content. Of course we could help search engines to index our site but if we don't have interesting articles and stuff it would be very hard.

We can acquire some extra traffic from social media but again if we don't have something really interesting it would be even harder. The book describes this techniques as SMO.

Another important thing about our website is external links - the more links are to our site the more chances are that someone will find us in the big world of Internet.

I must say that I was impressed by it. It's definetely worth reading. Everybody who is responsible in e-commerce should read it.

The book has also website connected with it:
http://www.seowarrior.net/

So if you're looking for companion of techniques and you're trying to prepare checklist want you need to do if you want to acquire some traffic to your website I can recommend this position as the good source of knowledge.