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. Цената е еквивалентна на споделения хостинг, но параметрите на услугата са много различни.

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

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

Free Tier Google Cloud VM

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

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

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: , , ,

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.

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: , ,

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: , ,

Dec 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 … в Швеция. В Бг не знам.

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

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

Tags: , , ,

Nov 22 2011

Нуждата от многоядрени процесори

Category: Dev,embedded,Нонсенс — Lucho @ 17:02


Част I

Защо аджеба имаме многоядрени процесори в стандартните персонални компютри?

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

Да вземем например процесор с 64 ядра. Всъщност дори и с 64 ядра… имаме 1 шина (северния мост), за достъп до паметта. Как 64 ядра могат ефективно да пишат и четата от паметта? Да не говорим за кеш кохийранс и потенциалните проблеми породени от false sharing-a.

Проблемът на многоядрените процесори са хората-мислещи-последователно-вместо-паралелно-защото-така-са-свикнали и достъпът до споделени ресурси. 64 ядра vs. една памет, един кеш, един кернел… и още много неща, които са по едно. Как 64 неща могат да работят ефективно с едно нещо едновремено и да са в синхрон – това е проблемът.

Защо нямаме едно ядро, което да върви на 64*3GHz?

Много уместен въпрос! Процесор с честота 192GHz звучи като решение на изначалния проблем – Защо да не си караме с едноядрен процесор на супер висока честота?

well…

  • Скоростта на светлината във вакуум е ~300 000 000 м/сек.
  • 192GHz са 192 000 000 000 такта в секунда

Простата сметка 300 000 000 / 192 000 000 000 = 1.5mm , показва че този процесор трябва да е голям около 1 милиметър (кв., куб.), за да може часовникът да разпространи сигнала си в него 192 милиарда пъти в секунда… и това са някакви груби, половинчати сметки. Това, което се опитвам да ви накарам да осъзнаете е че:

  1. Не може да поберете процесор в такова пространство.
  2. Ако поберете процесор в такова пространство ще ви трябва нещо по-студено от течен азот за да го охладите. Ще ви трябва и малка електроцентралка, за да го захраните.
  3. Ако успеете да намерите нещо по-бързо от светлината… good for you!

Част II

Единственият начин да имаме повече изчислителна мощ със сегашните закони на физиката е като имаме повече изчислителни устройства, които работят паралелно. За това си купувате 2-4-8 ядрени процесори на ниска честота (2 GHz).

Но един процес винаги върви на едно ядро – т.е. ако имате един единствен процес и искате да върви бързо, тогава ви трябва едно единствено ядро на висока честота (4 GHz например, вместо 2GHz). Това е миниатюрна частичка от един друг голям проблем – Ако имате програма, която изчислява някакъв резултат за X секунди на процесор с 1 ядро, нямате гаранция че ако пуснете програмата на процесор с 8 ядра със същата честота, тя ще върви 8 пъти по-бързо. Нещо повече, вашата програма може да върви дори по-бавно от колкото на 4 ядра. Т.е. вашият софтуер може да не се скалира добре върху многоядрена архитектура.

Това е като да си хирург в 13-ти век… взимаш някакъв труп и пориш, и изучаваш, и не разбираш, и си блъскаш главата… и след 100-200 години вече всичко е ясно и човечеството вече знае как работи човешкото тяло.

Ние сме в 13-ти век 🙂

Tags: ,

Next Page »