Tuesday, September 2, 2014

Чикаго 1-7 Сентября 2014 - мотопутешествие

С чего начинается мотопутешествие? Обычно с долгих приготовлений!

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

Купил палатку, прикольный самонадувающийся коврик и спальный мешок, купил набор походной посуды и портативную плитку для готовки на свежем воздухе.

Для Акулы прикупил гаджетов -- кейдж, защиту для рук, защиту заднего тормозного цилиндра, дуги безопасности чтобы поберечь верхние левые и правые бока в случае падения.

За неделю до поездки поменял моторное масло, проверил крепость затянутых болтов вокруг, состояние воздушного фильтра и прочее ТО.

А накануне наконец решил собрать весь свой скарб и примерить на байк. Оказалось что с креплением багажа я не все продумал: получилась внушительная гора (палатка, спальник и коврик), частично закрывающая стопари и поворотники,причем меня не удовлетворило качество крепления всей этой горы (из-за которой меня было чуть видно).

В итоге решил я изменить формат похода -- спать буду все же в мотелях. Понимаю что это не "по-настоящему" поход, но это уж лучше в следующий раз :)

Думаю мне следовало просто несколько раз съездить в "карманные" походы выходного дня перед этим большим, ну да ладно.

Весь мой скарб был распределен на 2 части -- электроника пошла в сумку на бак, остальное - на saddlebag, который я решил прикупить вместо боковых кофров. По отзывам вся эта конструкция легче алюминиевых кофров, да и дешевле раза в 3.

Выбор был остановлен на Coyote Saddlebags: http://giantloopmoto.com/products/coyote-saddlebag/

Итого, утром был готов и семья вышла меня провожать в полном составе. Вот собственно я за минуту до отъезда:


С утра несколько болела голова несмотря на таблетку цитрамона, так что музыку я решил не включать и прокатиться так как есть -- только ветер и шум мотора. 

Ехал и думал о разном. В частности, с чего бы это меня потянуло на такие приключения? А ведь тянуло давно, начиная с велосипедного периода жизни. Есть мысли на этот счет, и одна из них -- я нигде не чувствую себя дома. Вообще не чувствую. Поэтому пытаюсь найти там где почувствую. А как это сделать если не повидать как можно больше мест? 

Но понятно это не единственная причина по которой меня тянет в дорогу - мне нравится движение, ветер, и то как это ложится на мою "дорожную" музыку.

На первый день я собирался проехать 438 миль.

Вдоль американских хайвеев регулярно встречаются так называемые Rest Area и Text Area. Бывают что они сильно похожи друг надруга, но часто Text Area не имеют ни туалета, ни автоматов по продаже воды. Судя по предваряющим надписям в основном Text Area нужны чтобы остановиться и перезвонить или ответить на текстовое сообщение что не мешает однако людям просто останавливаться, сидеть за столиками и отдыхать :)

Я лично останавливался чтобы глотнуть воды да зачекинится через Foursquare Swarm





Первый день прошел без происшествий -- разве что как загорелся сигнал "топливо почти на нуле" немного стремно было шарить по окрестностям в поисках заправки, хотя резерва должно было хватать на километров 60. Но в поисках нормального бензина все равно проехал миль 15.

Наконец первый мотель -- Budget Inn. В самом деле budget -- приветливый индус на ресепшне отбил чек в $63

http://goo.gl/maps/vl1A6

Номера неплохие, так что конкретно это место можно смело рекомендовать! :)



Хочу отметить что американцы любопытный и приветливый народ -- даже несмотря на то что я останавливался раза 4 всего и то имел пару разговоров -- один раз дед рассказывал мне про BMW мотоциклы и свое увлечение ими (напомню что у меня BMW G650GS 2009 что практически идентично BMW F650GS 2000-2007 гг). Индус на ресепшне тож засыпал вопросами насчет моей экипировки, сколько стоит и куда еду :)

На конец дня башка моя все еще побаливала, поэтому завалился спать.

Следующий (т.е. уже сегодняшний) день -- это участок пути до Детройта где собираюсь глянуть на музей Генри  Форда

Wednesday, February 27, 2013

System Architect - what position will be next?

About 15 years ago I defined a goal for my career -- to became a system architect.

How you can decide whether your goals achieved?

I think that the most reliable mean to measure it - to fulfill the corresponding responsibilities and be accepted among professionals you are working with.

Once you have achieved it -- what's then?

If you do still love development, I think that the next step may be a consultant career.

Why?

Several reasons.

Because it may help you to share your experience among many teams making this world better! :)

At the same time you will be still able to gain much new experience because you'll be involved in many projects also allowing you to develop some non-development skills such as presentation skill.


Today EPAM Systems offered me a new opportunity -- a head of R&D center.

Prior that I passed a couple of interview and found out that this position correlates with my goal -- to became a well-known consultant like Martin Fowler :)


So I accepted this offer.

I consider it as a new step in my career and I'll do my best to became famous and accepted among professionals! :)

UPDATE:

Unfortunately, in one month I decided to accept job proposal from another company.

My decision was made because this way may lead me to achieve the goal which I was chasing when accepted EPAM job proposal more than one year ago (yep, I failed to achieve that goal while working in EPAM, sorry :( )

It was not very easy decision. I liked to work in CDP Team -- nice, smart people, good opportunities, knowledgable and nice boss.

But I believe that in a few years I will get back to consulting career! :)

Wednesday, January 23, 2013

Poor, confused C# compiler

A very interesting cause when C# compiled failed to handle a special case of cross-references in structures:

Poor, confused C# compiler

Now wonder that I don't know it! It's just because I don't use struct keyword very often :)

P.S. DON'T ASK THIS QUESTION DURING JOB INTERVIEW! INTERVIEWEE WOULD THINK THAT YOU ARE NOT VERY GOOD AT INTERVIEWING! :)

Friday, January 11, 2013

Need a real tasks -- tired to do nothing for a few months

I fed up with just sitting on my ass and inventing tasks on myself.

I paid well, but I paid for nothing.

If I don't do the work I love and this way my coding skills will degrade very quickly.

Recently I started to promote myself as a free-of-tasks specialist during my presentations, so finally one of my listeners came to me and proposed to join his team for a while to help his team to adopt BDD practice.

Will start on Monday afternoon.

I hope it will help me as well to restore my coding skills. It'll be a fun to work within a team as well.

Tuesday, December 11, 2012

Interview

How to conduct a correct interview?

I have passed many of them in both roles.

My opinion when I conduct such interviews is get to know whether a candidate is a problem-solving type.

What does it mean?

Does it mean that he will be able to know all technologies with all low-level details?..

I doubt.

Very often I interview candidates who are quite good at low-level details but have the lack of architectural skills and can't really provide a solution to my test task.

Do you need a developer who has low-level knowledge and don't have a glue how to solve problems?

Possibly, no.

I won't insist. May be there are situations when it does not matter whether a developer problem-solving type or not -- all what he is supposed to do is to serve as a codemonkey all day long.

But I am stick the following opinion: I'd rather hire a problem-solving type developer with good learning skills than developer who has impressive knowledge in web services, ASP .Net, or whatever-technology but was not able to understand a task and provide a good solution to solve it (no low-level details required -- they can be easily picked up from Google).

Saturday, December 8, 2012

improving education with www.codeacademy.com

I can recommend www.codeacademy.com site to everyone who needs to refresh his/her web-related knowledge, or even learn a new one.

It won't take a lot of time, but I found that this academy can save a lot of time :)

In example, I did not know CSS very well, but one of the courses gave me enough experience in a few hours. :)

S.O.L.I.D. presentation conducted!

Last Friday I conducted S.O.L.I.D. principles presentation in my company, EPAM Systems.


While I was working at Tau Craft, I tried to do it step-by-step, explaining one principle at a time.

But I stopped on the second stage -- Open-Closed Principle as I felt that I need to rethink my approach, them postponed it until this time.

Now I took a completely different approach supplying each principle with a huge amount of examples in Visual Studio 2012.

Combining live coding with theoretical part the whole things seemed more logical and memorable, so my auditory was quite satisfied (that was demonstrated by high course rates).

Let's see one good metaphor for Open-Closed Principle:
OCP

I found it during preparation and now believe that it's the best example I have ever seen! :)

There were some problems with Liskov Substitution Principle, but it went just fine thought it still needs to be improved (will do it).

The most debatable case was Dependency Inversion Principle:

DIP



We spent plenty of time discussing of how much granularity should be used.

And yes! Remember one thing: Dependency Inversion is not equal to Dependency Injection! They are often mixed out, but they should not! :)
Let's have a look at an example.

Before DIP applied:

 On this picture the layering is ok (consider namespace as an assembly/module).

UI depends on Business, Business depends on Data Access.

The DIP violated because two things:

1. UI depends on low-level detail (uses PointOfSaleTerminal class.
2. No abstractions at all.

After fixing we acquired the following picture:




 In this case dependencies were TRULY INVERTED!

All modules now depends on interface class.

I must mention that the key idea is that Dependency Injection is just a tool to implement Dependency Inversion.

You can find a good article about it in Dependency Injection is NOT The Same As The Dependency Inversion Principle by Derick Bailey