Дневна доза нонсенс…

Jun 22 2017

Преместих блога в Google Cloud

Category: Dev,Web — Lucho @ 17:45

Преди 8 години, когато създадох този блог, избрах сравнително най-евтиния и качествен споделен хостинг, който се предлага от българска фирма. Тогава цената беше около 40 лева на година, като от тогава всяка година тя расте. В днешно време фирмите, които предлагат хостинг в България изглеждат по-малко, но по-големи и вероятно с по-добро качество на услугата. Цената съответно варира, но най-скромният план на месец излиза по около 8-9 лева ($5), а за година около 100+ лева.

Това ме подтикна да разгледам други хостинг опции и също така cloud платформи, които предлагат виртуални машини. Оказва се, че най-минималната конфигурация, която може да се наеме от Google Cloud излиза около $5 на месец (прогнозна цена) и включва 20% от едно ядро с опцията да се използва цялото ядро в кратък интервал, 0.6 GB оперативна памет и твърд диск до 30GB. Цената е еквивалентна на споделения хостинг, но параметрите на услугата са много различни.

Хостингът има набор от полезен софтуер с графичен интерфейс, който позволява по-лесното му управление. От друга страна виртуалната машина има шел и няма никакви ограничения в това какво може да се инсталира на нея, което понякога е сериозен минус на хостинг решенията.
Софтуерът и хардуерът на хостинг решението се поддържа от фирмата, от която е нает, докато в cloud платформите инсталирането, конфигурацията и обновлението на софтуера е персонална отговорност.
Фирмите, които предлагат споделен хостинг рядко уточняват какви системни ресурси разполага наетият при тях хостинг, за това е трудно да се направи сравнение с виртуалната машина със споделено процесорно време и 0.6GB RAM. Ако приложенията, които ще вървят не консумират повече от ресурсите, които виртуалната машина предлага, тогава едва ли има видима разлика за крайния потребител в това отношение.
Редовното създаването на backup на файловата система и/или базата данни е включена услуга в плана на споделения хостинг, докато при cloud платформите може да е отговорност на потребителя или да се таксува допълнително.

Моят блог и приложенията, които вървят на текущия ми хостинг не са популярни и заемат малко ресурси, което наклони везната в полза на наета виртуална машина в Google Cloud. Преместването отне около ден, като най-трудно беше инсталирането на WordPress и плъгините му, тъй като реших да направя нова инсталация, защото старата wordpress инсталация на хостинга беше компроментирана преди време. Като бонус към миграцитя реших да инсталирам и безплатен TLS сертификат чрез https://letsencrypt.org/, което май е платена опция при споделния хостинг.

Free Tier Google Cloud VM

Google Cloud предлага $300 безплатен кредит в рамиките на 12 месеца, за да може новите потребители да тестват платформата им. Това беше и сериозна причина да опитам техните услуги, като текущата конфигурация е споделено процесорно време на едно ядро (50%), 1.7GB RAM, 15GB SSD за прогнозна цена от $15 на месец. След изтичането на периода мога да мигрирам машината към по-скромния вариант, който излиза около $5 на месец. От март месец Google имат и нова “Free Tier” оферта, която позволява наем на най-ниския им клас виртуална машина вместо за $5 за 0! Единственият недостатък е че виртуалната машина трябва да се намира в data center в САЩ, вместо в Европа и да използва твърд диск вместо SSD (иначе се заплаща). Тук има повече по темата: https://news.ycombinator.com/item?id=13832519

Възможно е след година да преместя инсталацията в нисък клас виртуална машина (безплатна), защото все пак този блог не е особено оживено място и може би ще се справи с минимални ресурси 😉

Comments (0)

Apr 01 2013

Easter Rail 4 todo app

Category: Dev,HTML5,Web — Lucho @ 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

Tags: github, heroku, html5, Ruby on Rails

Comments (0)

Dec 29 2012

Catch up with “the technologies”

Category: Dev,embedded — Lucho @ 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.

Comments (0)

Aug 09 2012

Keep calm and Code on

Category: Dev — Lucho @ 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

Tags: dvcs, mercurial, workflow

Comments (0)

Mar 22 2012

The 10 Coding Commandments

Category: Dev — Lucho @ 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). Пишете анотации към публичните методи поне. Не заради вас, а заради бъдещите несретници, които ще трябва да ви четат бакийте.

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

И блогнете за него 🙂

Tags: code, software development, software engineering

Comments (0)

Feb 06 2012