воскресенье, 9 ноября 2014 г.

Highload 2014

If you ever happened to hear about the biggest Russian IT conference Highload++, than you might be interested how it was. This is how it was for me this year: Highload 2014

I have deliberately chosen an external publishing platform for their beautiful storytelling format. Give it a try - Tilda.

Cheers.

вторник, 28 октября 2014 г.

Why REST is not JSON over HTTP

Because REST is distributed Hypermedia. THE END. 
Modern Web Architectures.

Enjoy.

четверг, 24 июля 2014 г.

Teach your code to speak genteelly, nil is country speach

Imagine you ask a person something, but he just stares at you in response. Or even worse, you tell one to do what you want, and he seems to get your command, but turns his back to you and you can't tell if he did what you asked him to or not. Did you imagine it?
Congratulations! You have just got nil/null, whatever represents nothingness in your programming language, in response to a function call.

The same way you think a person who doesn't react appropriately to your questions or requests is an ass-head, the same way function returning nil is a moron-function.

I do know that there are cases when you have nothing to return, but this is either a Special Case or an exceptional situation. Let's consider two examples for query and command. Yes, to be genteel your code have to comply with CQS principle. 

First - query. To be honest whether a special case or an exception is better depends very much on a context. Let's consider two query categories: query for data (information, data structure) and query for behaviour. First case is easy, you just fill your data structure with whatever it turns it to an empty state if it has a meaning or you raise an exception if you can't fulfill a query. Easy peasy. The second case is a little bit more complicated. Lets say, you write a polymorphic query function which is supposed to return objects with state and behaviour that may be used to do something. As long as it is polymorphic it is to change a behaviour when you work with descendant classes i.e. return different objects with different behaviour, but not every descendant alters a default behaviour. Oh, and there is no default behaviour. Natural choice? - Nil. But if I put it another way: to do nothing IS a default behaviour, it becomes obvious that your best bet is a Special Case with no op strategy, rather then nil, completely nothing. 

Now a command. I'd separate two kinds of commands: those that you do not expect to return a result and those you do. The first type is naturally implemented by procedures. Some programming languages have a void return type built in. This is probably the only valid case to return nothing. However, if your language of choice has no built-in tools to mark the function as a procedure then treat all commands as those that return result. In this case you'd probably return nothing in case you've failed to accomplish request, which is the worst way to do. Rather use an exception to inform a caller that his request puts you into an exceptional case when you can't process a command request.

All in all it is very easy to be polite to those who use your code and to those who read it. 

To be little bit more convincing I'll again reference one of the best programming books ever: Clean Code, and a very good discussion.

And as if that was not enough already I'd quote Sir Charles Antony Richard Hoare:
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. [...] More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.

P.S. Should I mention that passing nil/null as a function argument is even worse for very obvious reasons? 
P.P.S. I'd like to try a programming language without nils. Without nothing. You got it.

Cheers.

вторник, 20 мая 2014 г.

TDD and Rails are sister pills

Давеча, небезызвестный в одном коммюнити человек DHH разразился замечательным высером про TDD, который по его мнению ничто иное как артефакт, подобранный на помойке истории, а применение оного напоминает ему онанизм с элементами BDSM.

Многое было сказано в защиту TDD, больше даже не в защиту, а так, поржать

Но ведь, если предположить, что Zed Shaw хотя бы наполовину прав, то сейчас вся толпа, которая разинув рот внимает божеству, бросится бросать и начнет начинать все сначала. 

Всем давно понятно, что OOP это лекарство чуть ли не хуже болезни, процесс принятия которого нужно сопровождать пилюлями типа TDD, BDD, DDD, чтобы пореже обкакиваться. Но у этих пилюль свои побочные эффекты и для них нужны другие пилюли типа autofixture (это вам .Net камарады подгон), DCI (а это скорее нам Ruby парням, обломитесь диназавры =Р).

Впрочем, если лекарство разбавлять, то все не так уж плохо. К примеру, у Udi Dahan есть много оригинальных идей, однако они относятся к разработке систем, а не приложений (разница я надеюсь понятна). А так ли нужен OOP для разработки приложений, а тем более TDD?
Может быть basecamp все же не все приложения/системы на свете, и надо быть более openminded, а DHH? Как-то даже странно это спрашивать у человека, который насрал на OOP в пользу developer productivity, ведь чтобы срать грамотно, надо быть openminded. 

Cознательно возведя productivity в краеугольный принцип Rails, DHH поставил его в одну категорию с TDD. Они суть две пилюли с разным действием, и вместе они не работают, т.к. мешают друг другу. 

Ну вот собственно и объяснение. Удачи.

четверг, 27 марта 2014 г.

Rails vs OOP or is it Rails feat. OOP?

Please mind that this note is as opinionated as can be. I believe this is the only way one can speak about Rails as RoR itself leave no room for doubts.

I believe Rails was meant for small to middle web sites development, and never meant to be a foundation for something bigger. Just read 37signalsGetting Real book and you will understand that Rails is backed by a company with a no-grow philosophy. And so is Rails - it will never be as big as Java or .Net are. 

You can ignore this until you start develop a little bit more elaborate software. And this is where you have to get serious about OOP. But Rails provides no aid here. Instead, it leads you into trouble, because it puts too much pressure on you with conventions and especially with poor naming. (I am not trying to charge DHH with that, after all naming is the weakest skill in IT community of all times.) Thousands of people fall into problems of not understanding where they should rethink Rails conventions and deviate from them, which leads to heated discussions whether Rails breaks OOP and how to keep producing quality maintainable and testable code with Rails (fat models/skinny controllers attempt, writing true unit-tests with Rails, is ActiveRecord an anti-pattern, etc). Well the answer is - get to know some OOP theory. These are the problems OOP community have been solving for decades now and there is nothing really new about that. 

Oh wait, there is something new! Rails deserves special gratitude for whetting community appetite for least known DCI design pattern. 

Rails community experience lot's of agitation and controversy, and this couldn't be another way. The reason for this is that RoR emphasizes on developers' productivity at the first place rather then being dogmatic about design. Understanding this may turn us to be a little bit less dogmatic about Rails' usage.

More to read:
https://gettingreal.37signals.com/
http://railsoopbook.com/
http://objectsonrails.com/
http://www.leansoftwarearchitecture.com/
http://clean-ruby.com/
http://www.artima.com/articles/dci_vision.html
http://folk.uio.no/trygver/2008/commonsense.pdf

Good luck!