апр 01 2013

Easter Rail 4 todo app

Category: Dev,HTML5,WebLucho @ 14:33

So, it is that time of the year when you have 4 free days, because it is Easter and at the same time Rails 4 and Ruby 2 got out recently and you have not touched Ruby and Rails in ages. As we all know, when the life throws at you new Ruby and new Rails you must make a lemonade or at least a hello world-ish todo app out of this (also it helps to refresh your lost rails-fu points).

The result of my efforts is on github and the application is demoed on heroku.

This time I was clever enough to write down all important steps and obstacles on my way, so I have a „lessons learned“ section for future me (if future me is going to start a bigger project on Rails 4 any day).

I also had the chance to pick up on HTML5 Boilerplate, jQuery 2 and Giphy API, which just boost indefinitely the awesomeness of the todo app. The only bad thing was that Giphy’s API seems very undergroundish, or at least I could not find any official documentation about it, so I just followed examples from other github repos.

One last thing – heroku deployment is still a serious pain in the arse1!!12 I MEAN IT!! The only positive thing out of this is that I learned how to git rebase –interactive and squash 14 heroku-should-work-now commits in one – I leveled up in git.

nyan

 


Етикети: , , ,


дек 29 2012

Catch up with „the technologies“

Category: Dev,embeddedLucho @ 19:06

While I am waiting to get my Raspberry Pi and making plans what to do with it (probably a Raspbmc) I started promoting friends of mine about raspberypi.org. Some of them were familiar with it already or got really enthusiastic, others replied „I don’t see any practical use of it“. That is true, you can not find practical use of something you have not seen or played with yet. That is why you need to get one – to be able to find any application of it in your work or life. And if you can’t … well, may be then you should be allowed to say „I don’t see any practical use of it“.

I bought Arduino starter kit this summer and I did not make anything meaningful out of it. Instead of that, I actually made something funny and exciting (for me at least) out of it.

Well, the original idea was to build obstacle avoiding robot based on Arduino, but then the KTH semester started and I got overwhelmed with other less funny and exciting stuff. Never the less, I got my hands dirty with that board and now I know better what are the limitations and the features of it. And this is what matters.

By the way, in Swedish „semester“ means „vacation“. I know, right.

I leave you with one awesome TED talk, which friend of mine shared with me. The key concept stated in it is – People don’t buy what you do, they buy why you do it.

If you see Arduino, Raspberry Pi or any other piece of technology only as „what“ and you are not passionate about it, then you are screwed. Sorry :P.



авг 09 2012

Keep calm and Code on

Category: DevLucho @ 18:35

I. Keep calm and keep the default branch clean and ready for deploy… ALWAYS!  

# just do it

 

II. Keep calm and use Named Branches for every new feature:

hg pull # get all the changes so far
hg update -C default # go to the default branch and clean it from untracked files

hg branch my_new_feature
hg commit -m ‘initial commit for my_new_feature’
hg push –new-branch # the new branch is in the repository now
# continue working as usual up to the moment when you have to merge your changes

 

III. Keep calm and set tags for every deployed version:

# – yey, we have just deployed. Let’s put a tag in Mercurial.
hg tag v1.0

# … 1 week later.
# – jeez, there’s a bug, but we can not reproduce it by the current code base in the default…
# – well, then just rollback to the latest release version – v1.0

hg update v1.0
hg branch my_fix_in_v1.0
hg commit -m ‘initial commit in my_fix_in_v1.0′
# make your fix and merge to the default later

 

IV. Keep calm and read on here:

http://bit.ly/cvwklr Chapter 8. Managing releases and branchy development


Етикети: , ,


мар 22 2012

The 10 Coding Commandments

Category: DevLucho @ 23:33

1. DRY: DON’T REPEAT YOURSELF

Повторението е майка на знанието и баща на затъпяването. Особено неприятно е ако пишете код предимно чрез копи/пейст и в един момент трябва да промените едно и също нещо на 12 места. Не го правете. Изнасяйте общата функционалност в абстрактни класове или някъде другаде.

2. CREATE LOTS OF UNIT TESTS. TESTS ARE AWESOME

Юнит тестове, интеграционни тестове, пърформанс тестове – най-сигурният начин да покажете, че нещо не работи. Програмирането е инкрементален процес – всичко се случва малко по малко, стъпка по стъпка. Лесно и бързо е ако имате код, който проверява стъпките ви автоматично, а не ръчно както би ви се наложило иначе.

3. REFACTOR OFTEN AND SOONER. DON’T BE LAZY

Първоначалният вариант на кода вероятно ще е нещо, което ще нарушава доста от точките изброени в тази статия. Това не е проблем стига да следвате №2. Веднъж, щом имате идея какво трябва да прави кодът и как да го прави по-оптимално просто пренаписвате части от имплементацията и с божията помощ и достатъчно тестове, които да проверят поведението й, вероятно всичко ще е наред.

4. CODE TO AN INTERFACE, NOT TO AN IMPLEMENTATION

Разделете програмата си на колкото се може повече логически модули. Тези модули комуникират помежду си чрез интерфейси. Това намалява сложността, защото един клас от 1000 реда се тества, поддържа, чете по-трудно отколкото два по 500 реда. Разделяй и владей.

5. WRITE SHORT METHODS. SHORT METHODS ARE AWESOME

Ако не можете да обясните нещо кратко и ясно, тогава не го разбирате достатъчно добре. Ако имате обемен и сложен метод, по-добре го разбийте на няколко по-малки. Никой не обича да чете дълги и сложни писания.

6. BRANCH ON NEW FEATURES AND BUGFIXES

Ако ползвате SVN вероятно тази точка няма да ви пасне толкова добре, колкото ако ползвате децентрализирана система за контрол на версиите на кода като Git или Mercurial. Целта е всяка обемна нова функционалност да си има собствен бранч, така че да можете да работите по нея когато и колкото си искате и всъщото време трънка да държи само стабилна версия на приложението ви.

7. PREMATURE OPTIMIZATION IS THE ROOT OF ALL EVIL

Преди години работих върху игра за мобилни телефони и реших да пиша супер оптимален код. Някъде една седмица след като написах по-голямата част от този „супер оптимален“ код вече бях изгубил идея за логиката му. Загуба на време е. Ако се налага да се оптимизира нещо, го правете след като функционалността е завършена и има тестове за нея. Най-скъпият ресурс на един проект е времето за подръжка и разработка – не го раздувайте излишно за няколко процента по-бързо изпълнение.

Цитатът е на Доналд Кнут.

8. DRY: DON’T REPEAT YOURSELF

See #1 :)

9. THROW EXCEPTIONS. EXCEPTIONS ARE AWESOME

Освен ако не пишете на С нямате сериозна причина да не използвате изключения. Ако се случи нещо непредвидено просто хвърлете изключение. Не случайно се казва изключение. Не връщайте -1 или булева стойност или някаква друга глупост. Не обременявайте дизайна на приложението си излишно. Просто хвърляйте изключения във всеки изключителен случай ;-)

10. DON’T FORGET TO DOCUMENT YOUR CODE

Пишете самодокументиращ се код. Пишете документация към кода във формата на коментари, особено ако правите нещо сложно или извратено (като оптимизиране например :P). Пишете анотации към публичните методи поне. Не заради вас, а заради бъдещите несретници, които ще трябва да ви четат бакийте.

Тези правила може да не пасват на вас или вашият проект. Може би вече ги изпълнявате. Няма значение, все има нещо, което ви куца. Напишете го на лист хартия, сложете го до монитора и почнете да го следвате.

И блогнете за него :)


Етикети: , ,


фев 06 2012

Random ads

Category: НонсенсLucho @ 02:20

Krilleeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeh :D


Етикети: ,


яну 03 2012

Прах при прахта…

Category: Нонсенс,СоциалниLucho @ 04:34

Всички лаптопи, които съм имал за сега винаги са давали фира година след като ги ползвам. И все по един и същ начин – вентилатора им започва да трака. А започва да трака, защото е пълен с прах и иска смазване.

Вероятно не съм сам на света с този проблем. Даже мисля, че е доста често срещан и не разбирам защо все още трябва да разглобя всичко, което може да се разглоби, за да почистя и смажа една перка.

Ето и резултата от оставяне на лаптопа ви върху легло, дивани и мебели като цяло:

Една топка прах, която седи на изхода на вентилацията.

Хубавото от цялата история е, че успях да го сглобя и даже изглежда, че работи след като мога да напиша цяла статия от него :-)

 


Етикети: ,


дек 07 2011

Network of Things

Category: Dev,embedded,НеБългария,НонсенсLucho @ 20:32

50 000 000 000

Ако преди 20 години малко хора са си представяли, че от WWW ще произлезе нещо огромно и ако преди 10 години малко хора са си представяли, че ще браузват интернет от телефоните си, то не е трудно да си представим колко малко хора си представят, че след 20 години хладилниците и пералните ни ще си комуникират по между си.

Ериксън се опитва да натрапи тази идея:

И най-вероятно това ще се случи.

2050 година, 50 милиарда устройства свързани в мрежа, 10% от общия трафик на данни ще е генериран от хора (останалото от машини), експоненциален ръст на обмена на данни всяка година, хладилникът и пералнята ви си говорят… think about it.

В момента естествено сме относително далеч от това. Bandwidth-a още е много малък, за да може това да се реализира.

LTE

Long Term Evolution или алтернатива на WiMax за 4G свързаност. Пълен дуплекс с времеделене (time-division) – два канала за пренос на данни вървящи паралелно, 300Mbit/s down-link.

Първият 4G базиран на LTE е баш в Швеция, оператора се казва Telia… и кой друг освен Ериксън може да е изработил мрежата им :).

Btw, ако спрете клипчето на 1:01 минута, ще видите че това на екрана е media player… it’s ALL LIES!

Battery

Другата голяма спънка да не се замеряме с 4G телефони в момента са батериите. Скоростния обмен на данни харчи ток. Доста ток.

За това и няма много телефони, които да са с 4G… но скоро идват – Samsung Galaxy S2 LTE … в Швеция. В Бг не знам.

Батериите зависят от химиците. Ако сте химик, моля, побързайте да направите някоя по-сносна батерия :D

Това са парчетата от пъзела. Бъдещето звучи яко, а ;-)


Етикети: , , ,


Следваща страница »