There probably has been billions of articles written about this topic, and I am no expert who understands the full extent on how the two types of project differ from each other. However, most of those articles are fairly old, and the year 2011 deserves a new article about this topic. :)
So if you are a developer working in a Microsoft shop, chances are you would use at least one of the following: ASP.NET MVC, NuGet, Unity Application Block, Unit Test, Gated Check-in, custom build event/script.
If you use any of those consistently in your projects, it's probably best to stick with Web Application Project, some of them (i.e. ASP.NET MVC) flat out cannot work with Website Project; some would, but requires non-typical setup which you have to investigate and assess.
Conclusion: in year 2011, if you are not sure, use Web Application Project.
Sharing my thoughts on software development
Friday, July 29, 2011
Thursday, July 28, 2011
CoffeeScript global variable and @ keyword
I finally managed to pick up CoffeeScript, by writing a small game using CoffeeScript and Canvas. Writing code with CoffeeScript is a very fluent experience, even though I have never used Ruby and have C# background, the syntax feels so natural and code enjoyable to write. All the good things aside, I also got caught by a little gotcha of the language.
In the world of CoffeeScript, global variables must be explicitly declared, using either @ or window keyword, and most tutorials recommend @ due to its succinctness:
this attaches luckyNumber into window object and thus accessible globally. The tricky thing is if you do the same declaration in a class:
all of sudden, @luckyNumber becomes a property of MyClass, and is not attached to the window object anymore! Now consider following situation:
Is it going to give you 4 or 5? ... Yes you probably guessed right, it's 5. To access the global variable, you need:
In the world of CoffeeScript, global variables must be explicitly declared, using either @ or window keyword, and most tutorials recommend @ due to its succinctness:
@luckyNumber = 4
this attaches luckyNumber into window object and thus accessible globally. The tricky thing is if you do the same declaration in a class:
class MyClass constructor: (@luckyNumber = 5) ->
all of sudden, @luckyNumber becomes a property of MyClass, and is not attached to the window object anymore! Now consider following situation:
@luckyNumber = 4
class MyClass
constructor: (@luckyNumber = 5) ->
showLuckyNumber: () ->
alert(@luckyNumber)
(new MyClass).showLuckyNumber()
Is it going to give you 4 or 5? ... Yes you probably guessed right, it's 5. To access the global variable, you need:
showLuckyNumber: () ->
alert(window.luckyNumber)
While tricky, this is not exactly a CoffeeScript problem, but weirdness inherited from Javascript. Remember the golden rule: "It's just JavaScript".Wednesday, September 15, 2010
A redemption of Waterfall model
It is almost common knowledge now that waterfall model does not work, especially if you talk to programmers leaning to the agile persuasion. In this article I am going to give waterfall model its deserved credit, and to look at software development from a different perspective.
Before start, I need to first make a disclaimer -- I am not talking about "strict" waterfall or "strict" agile, I don't think those extreme cases apply to most real life situations.To me, any development processes that falls into defining clear phases (initiation, analysis, design, development, testing) are using waterfall model, regardless compromises made to accommodate different circumstances.
First, let's talk a little about history. Waterfall model originated from manufacturing and construction industries, the waterfall model does not only suits the limitation of the projects of those industries (where flexibility is impossible when real goods are involved), but also suits their management method -- The Command and Control Management Method.
If a company using command and control management method tries to use agile development model, guess what will happen? Well, agile practices rely heavily on making constant changes based on new discoveries and shifting requirements which will need to travel back to the top and come back down to the developers. When too many changes are pending, the decision maker becomes a bottleneck while the developers are held up until a decision can be made. This does not only creates more pressure on the decision maker but also would actually delay the project delivery.
On the other hand, waterfall model tends to minimize the communication requirement between decision maker and developers. When the project is in analysis/design phase, developers can be given other tasks like maintaining existing projects. Once the construction starts, developers are called in and start doing the work. There will be only occasional cases when changes are needed AND possible, giving the decision maker plenty leisure to examine issues popping up without delaying the project much.
Of course, the better solution would be to change the management process to be more decentralized to avoid decision making bottleneck. But unfortunately, real life situations are normally far from ideal. Maybe there aren't enough competent developers to delegate responsibilities to (and no, you don't want to set everybody lose to wreck havoc to the code base); or the company has been burnt by having too many fingers making decisions; or the business model can tolerate low quality software thus improving the development process is lower priority; or maybe simply just because.
You have to really think hard about the situation before applying any best practices or the hottest methodologies. Sometimes you may have to make compromises and take the second-best option.
Before start, I need to first make a disclaimer -- I am not talking about "strict" waterfall or "strict" agile, I don't think those extreme cases apply to most real life situations.To me, any development processes that falls into defining clear phases (initiation, analysis, design, development, testing) are using waterfall model, regardless compromises made to accommodate different circumstances.
First, let's talk a little about history. Waterfall model originated from manufacturing and construction industries, the waterfall model does not only suits the limitation of the projects of those industries (where flexibility is impossible when real goods are involved), but also suits their management method -- The Command and Control Management Method.
If a company using command and control management method tries to use agile development model, guess what will happen? Well, agile practices rely heavily on making constant changes based on new discoveries and shifting requirements which will need to travel back to the top and come back down to the developers. When too many changes are pending, the decision maker becomes a bottleneck while the developers are held up until a decision can be made. This does not only creates more pressure on the decision maker but also would actually delay the project delivery.
On the other hand, waterfall model tends to minimize the communication requirement between decision maker and developers. When the project is in analysis/design phase, developers can be given other tasks like maintaining existing projects. Once the construction starts, developers are called in and start doing the work. There will be only occasional cases when changes are needed AND possible, giving the decision maker plenty leisure to examine issues popping up without delaying the project much.
Of course, the better solution would be to change the management process to be more decentralized to avoid decision making bottleneck. But unfortunately, real life situations are normally far from ideal. Maybe there aren't enough competent developers to delegate responsibilities to (and no, you don't want to set everybody lose to wreck havoc to the code base); or the company has been burnt by having too many fingers making decisions; or the business model can tolerate low quality software thus improving the development process is lower priority; or maybe simply just because.
You have to really think hard about the situation before applying any best practices or the hottest methodologies. Sometimes you may have to make compromises and take the second-best option.
Monday, August 9, 2010
Premature Abstraction
Everyone knows that premature optimization is root of all evil and in extreme cases the programmer who does such thing will be stoned to death.
But not many people seem to be bothered with premature abstraction, or encapsulation or whatever people fancy it. Here is what I mean by premature abstraction: creating a train of complex framework to perform simple tasks to make them future proof.
This is a natural tendency after becoming more and more fluent in OO design, as one of the main advantage of OO is abstraction, to make code reusable and extensible. But like making a dish, if you put in too much of any sauce, it will ruin the taste. Abstraction is no exception.
Here is what will actually happen when you design something to be "future-proof": most of the anticipated requirements will be forgotten, and many new ones will show up from no where and on things you never thought of. When such thing happens, it'll be a painful experience to refactor that neatly designed and implemented framework to accommodate new requirements. If the project happen to be behind schedule at the time, which is always, guess what, you may not get the leisure and time to refactor the framework and hacks/workarounds will be applied to make it even harder to refactor. In fact once enough duct-tape is being applied to that originally neatly designed framework, nobody will dare to touch it any more.
Now I think about it, there is actually a proper name for it: it is called over-engineering. And it is quickly surpassing premature optimization to become the new root of all evil.
I will stone you next time I see you do that.
But not many people seem to be bothered with premature abstraction, or encapsulation or whatever people fancy it. Here is what I mean by premature abstraction: creating a train of complex framework to perform simple tasks to make them future proof.
This is a natural tendency after becoming more and more fluent in OO design, as one of the main advantage of OO is abstraction, to make code reusable and extensible. But like making a dish, if you put in too much of any sauce, it will ruin the taste. Abstraction is no exception.
Here is what will actually happen when you design something to be "future-proof": most of the anticipated requirements will be forgotten, and many new ones will show up from no where and on things you never thought of. When such thing happens, it'll be a painful experience to refactor that neatly designed and implemented framework to accommodate new requirements. If the project happen to be behind schedule at the time, which is always, guess what, you may not get the leisure and time to refactor the framework and hacks/workarounds will be applied to make it even harder to refactor. In fact once enough duct-tape is being applied to that originally neatly designed framework, nobody will dare to touch it any more.
Now I think about it, there is actually a proper name for it: it is called over-engineering. And it is quickly surpassing premature optimization to become the new root of all evil.
I will stone you next time I see you do that.
Friday, March 5, 2010
You don't need a publisher
I was talking to my imaginative friend Joe the other day, trying to figure out why there still hasn't been a good website to read novels. We were talking about why book publishers should release books online in this era of Internet, and it struck me, why was publishers needed in the first place?
Back in the days, book publishing was a huge task and no small entities (a.k.a. authors) can do it for themselves, and in order to reach a wider audience without devoting their life to marketing which many may not be good at, book publishers were necessary.In fact things haven't changed much since! Book publishing is still a tremendous effort, you have to get editors to review the book, get advertisers to market the book, get designers to do book design, get printing companies to print the book, then go through a chain of distribution to get the books to readers.
And the result of that? Authors don't make that much. According to this post from a New York Times best selling author, she made a staggering $24,517.36 on a book that sold for 61,663 copies, about 40 cents for every book that's sold for $7.99 at retail. That's very little, but considering the amount of work the publisher has to do, it is only fair. Or is it?
In a business partnership, each partner has to contribute value to the business and take his/her share of profit based on the contribution, it is not always easily measurable, but mostly fair or the partnership won't work. Let's take a look what publisher brings to the table, that warrant a 95% cut [1].
Editor Review
Editors are quite helpful as they check for spelling, grammar and logical errors,they also give some good advices to improve the book or edit it directly.
Marketing
While authors can do a lot of the marketing themselves (and are increasingly required to), paid marketing campaign and advertisement still have their values. After all, who don't want to sell a few more books?
Printing and Distribution
These are normally done by separate companies. Printing and distribution is a lot of work, and book shelves are costly.
Publishers are indeed bringing a lot to the table in traditional publishing practice to warrant their share of profit. But things has changed! Advance in computer technology and the Internet has made a lot of things obsolete, including publishers, and here is why:
Editor Review
Spell checkers will weed out most of the typos and simple errors. Some helpful readers or a fellow author could definitely be able to help to do the proofreading to find any logical errors. In fact the readers will feel delighted to have a sneak peek into your newest book, it's a privilege! And even if errors manage to loom into your book, you can always go back and fix it, a luxury you don't have with paper backs.
And what beats reader feedback on how to improve your book? After all, the definition of a good book is that people like it enough that they will buy it.
Marketing
Authors already do a lot of marketing these days, and with the help of Internet, self-promotion has not been easier! If you really think you need some professional marketing, no one can stop you from hiring a marketing company, and you get to decide whether that's worth it.
Printing and Distribution
Need to say no more, distributing books online cost a fraction of traditional printing and distribution model. And there is always print-on-demand option for readers who prefer paperback.
Notes:
[1] To publishers' defense, they do not take 95% of the sales, money goes to all parties involved in the process of publishing a book. But to an author, it doesn't make a difference where the money went.
Back in the days, book publishing was a huge task and no small entities (a.k.a. authors) can do it for themselves, and in order to reach a wider audience without devoting their life to marketing which many may not be good at, book publishers were necessary.In fact things haven't changed much since! Book publishing is still a tremendous effort, you have to get editors to review the book, get advertisers to market the book, get designers to do book design, get printing companies to print the book, then go through a chain of distribution to get the books to readers.
And the result of that? Authors don't make that much. According to this post from a New York Times best selling author, she made a staggering $24,517.36 on a book that sold for 61,663 copies, about 40 cents for every book that's sold for $7.99 at retail. That's very little, but considering the amount of work the publisher has to do, it is only fair. Or is it?
In a business partnership, each partner has to contribute value to the business and take his/her share of profit based on the contribution, it is not always easily measurable, but mostly fair or the partnership won't work. Let's take a look what publisher brings to the table, that warrant a 95% cut [1].
Editor Review
Editors are quite helpful as they check for spelling, grammar and logical errors,they also give some good advices to improve the book or edit it directly.
Marketing
While authors can do a lot of the marketing themselves (and are increasingly required to), paid marketing campaign and advertisement still have their values. After all, who don't want to sell a few more books?
Printing and Distribution
These are normally done by separate companies. Printing and distribution is a lot of work, and book shelves are costly.
Publishers are indeed bringing a lot to the table in traditional publishing practice to warrant their share of profit. But things has changed! Advance in computer technology and the Internet has made a lot of things obsolete, including publishers, and here is why:
Editor Review
Spell checkers will weed out most of the typos and simple errors. Some helpful readers or a fellow author could definitely be able to help to do the proofreading to find any logical errors. In fact the readers will feel delighted to have a sneak peek into your newest book, it's a privilege! And even if errors manage to loom into your book, you can always go back and fix it, a luxury you don't have with paper backs.
And what beats reader feedback on how to improve your book? After all, the definition of a good book is that people like it enough that they will buy it.
Marketing
Authors already do a lot of marketing these days, and with the help of Internet, self-promotion has not been easier! If you really think you need some professional marketing, no one can stop you from hiring a marketing company, and you get to decide whether that's worth it.
Printing and Distribution
Need to say no more, distributing books online cost a fraction of traditional printing and distribution model. And there is always print-on-demand option for readers who prefer paperback.
Notes:
[1] To publishers' defense, they do not take 95% of the sales, money goes to all parties involved in the process of publishing a book. But to an author, it doesn't make a difference where the money went.
Subscribe to:
Posts (Atom)