Dmitry Podgorniy, posts tagged: по-русски

Сложно, просто, трудно, легко

Fri, 19 Jun 2015 19:41:03 +0200

Памятка

Сложно – состоит из множества частей. Аналог английского complex.
Просто – состоит из много меньшего количества вещей, чем сложный объект simple.
Трудно – требует наличие дополнительных навыков или опыта difficult.
Легко – требует меньше дополнительных навыков или опыта easy.

Даже опытные путают простые, понятные вещи с легкими. Чтобы не перепутать, нужно думать о задаче как человек без опыта.

Опыт, know-how – знание, упрощенный алгоритм, представление о явлении или действии. Зачастую появляется как результат анализа как ошибок, так и успехов (анализ ошибок проводится далеко не всеми).

Комплексы простых вещей превращаются в трудные.

Как проверить содержательность разговора

Mon, 04 May 2015 08:20:51 +0200

Прочти диалог в обратном порядке (снизу-вверх, сначала ответы, потом вопросы) и оцени связь ответов с вопросами.

Как улучшить себя как программиста

Thu, 23 Apr 2015 12:52:28 +0200

Думай категориями издержек и прибыли.

Тебя делает лучше все то, что позволяет более эффективно (с меньшими издержками) достигать результата.

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

Сравнение техник, новых и старых библиотек, фреймверков, подходов к организации команды сводится к центральной объективной характеристике: количество издержек. Богатство советов программистам является частными проявлениями урезания издержек. Например статьи о программистах, решающих задачу, не написав ни единой строки кода есть ничто иное, как получение результата и урезание издержек. Единообразие кода, качественное форматирование позволяет сохранить время команде при чтении кода. Использование системы контроля версий уменьшает издержки на координацию работы в команде.

Автоматизировать все что можно автоматизировать – частное проявление урезания издержек в виде человеческого участия и внимания задачам, которые можно автоматизировать.

Модульный подход к архитектуре, использование фреймверков – это все инструменты для урезания издержек.

Как принимать решение:

Оценить соотношение издержек и прибыли рассматриваемых вариантов решения.

Прелесть подхода заключается в его универсальности: даже не имея опыта в программировании, можно выдвигать предположения исходя из чужого опыта, подчерпнутого в блогах и на конференциях. С опытом, более полной картиной мира можно принимать более выгодные решения.

Почему серебряной пули нет

Wed, 22 Apr 2015 16:49:33 +0200

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

Лучшее регулярное выражение для валидации email в web формах

Tue, 21 Apr 2015 18:19:11 +0200

/[^@]+@[^@\.]+\.[^@]+/

Оговорка “на клиенте” сделана не просто так. Задача валидации на клиенте – подсказать пользователю, где он ошибся в написании email-а. Важно случайным образом не запретить пользователю с непредусмотренным емейлом воспользоваться формой. Учитывая то, какие варианты емейла могут быть (неожиданные домены, появляющиеся по пучку каждый месяц, ip адреса в качестве домена, и символы точки и симполы +, и другие неизвестные широкому обывателю вещи), напрашивается вывод, что лучшая валидация проверит емейл на наличие текста вида текст-собачка-текст-точка-текст.

Не замечаешь пока работает

Mon, 20 Apr 2015 21:32:27 +0200

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

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

Удачность решения можно оценить только когда поймешь сколько ресурсов надо было бы потратить, если бы решение оказалось иным. Только опыт позволит отличить удачное решение от неудачного.

О meteorjs

Thu, 11 Dec 2014 22:58:52 +0200

Метеор – фреймверк, который включает в себя полный стек разработки: клиент, сервер, бд. Метеор реализовал собой концепцию “один и тот же код для клиента и сервера”.

Я начал знакомство с этим фреймверком с версии 0.4, уже два года как. Параллельно я смотрел на другие инструменты, разрешающие те же задачи, что и метеор (expressjs, socketio, sailsjs, backbone, mongoosejs, swarmjs, react, и другие, названия которых так и не вспомню). Я искал и подбирал те инструменты, которые позволят быть мне продуктивным, создавать и поддерживать проекты самостоятельно. Инструмента лучше метеора, я не нашел.

Что делает метеор: он радикально упрощает разработку приложений.

Используется один и тот же код для сервера и клиента. Я рад, что был выбран чистый js, а не какой-нить кофе (хотя код на кофе можно использовать наравне с js, нужно только добавить соответствующий пакет).
Подход к работе с базой данных на клиенте и сервере одинаковый. Один и тот же код работы с данными используется как для клиента, так и для сервера. Это достигается эмуляцией mongo api в браузере (с некоторыми ограничениями). Ограничение данных, доступных для клиента описывается в одном месте.
Большинство вещей, нужных для разработки идут из коробки: бутсрапинг приложения, темплейты, данные, пакетная система, сборка-минификация проекта, работа с аккаунтами и почтой. Бесплатный хостинг и деплой на него в одну команду. Пока не хватает нативного деплоймент менеджера из коробки (сейчас пользуюсь сторонним https://github.com/arunoda/meteor-up, деплою на digitalocean, ненарадуюсь), не хватает фреймверка для тестирования из коробки. Над этими пакетами сейчас идет работа.
Концепция реактивности. Код пишется так, что за обновлением данных на сервере следует немедленная реакция всех клиентов. На клиенте изменения данных отражаются автоматически на отображении страницы. Весь код, необходимый реактивности уже вшит в фреймверк (в работу с бд, темплейтами, сессионными данными). Работа с фреймверком сводится чисто к манипуляции с данными, без необходимости писать обертки-сихронизаторы, пробрасывать события, чтобы связать изменения зависимых данных.

Почему метеор имеет значение. История показывает, что выживают те технологии, которые решают задачи лучше других. Такие технологии как PHP, javascript выжили и распространились в большей степени не от того, что они хороши сами по себе, а потому что лучше других решали задачи (генерация html, и оживление страничек в браузере). Так вот метеор – это та технология, которая лучше других справляется с теми задачами, которые сегодня стоят перед веб разработчиками (работа с бд, изоляция вьюх, “умные” теплейты, деплой). javascript как язык, на котором говорит веб, одинаковые концепции для сервера и клиента, отсутствие необходимости совершать выбор стека технологий, необходимые инструменты из коробки: все это делает разработку на метеоре намного проще, если сравнивать с разработкой на самособранном стеке (сервер expressjs или connect, база mongodb, орм для базы mongoose, сокет-сервер socketio, клиент angular, backbone + react, что-то для деплоя и т. д.).

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

Из минусов.

Метеор – это полный стек. И так или иначе придется мириться с тем выбором, который был сделан создателями (в плане движка теплейтов, реактивности, подхода к работе с событиями и т. д.). Я понимаю, что хочется использовать знакомые вещи вместо незнакомых потому что так проще. Поэтому я считаю что метеор не подходит для тех, кто не готов довериться этому стеку технологий.
Целый набор новых парадигм (во всяком случае подходы метеора отличаются от тех, с которыми я сталкивался, разрабатывая сайты на expressjs и socketio). Новые парадигмы порождают непривычные проблемы. Попытка применить опыт разработки на том же expressjs к работе с метеором ведет к большему количеству вопросов, чем ответов.
Не поддерживается windows. Разработку из под винды вести сегодня не получится. Поддержка винды – это то, над чем сейчас активно ведется работа.

Для знакомства с технологией:

Пошаговый туториал
https://www.meteor.com/install

Документация на английском
http://docs.meteor.com/#/full/

Книженция, где создают приложение на метеоре
https://www.discovermeteor.com
и ее перевод http://ru.discovermeteor.com/

Годный блог про то как работают кишечки фреймверка
http://meteorhacks.com

Поиграться с метеором без необходимости его устанавливать (или чтобы поразрабатывать из-под винды):
http://meteorpad.com

Раздел форума, где я могу помочь и подсказать по метеору
http://forum.jscourse.com/c/meteor

Наблюдения за собой и другими при обучении

Wed, 10 Dec 2014 00:29:10 +0200

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

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

Знание названия терминов и употребление терминов вовремя не означает понимания сути предмета. Это может быть результат “заучивания”. Просьба описать явление своими словами с минимум терминов расставляет все на свои места. Тем не менее термины нужны, чтобы сохранить время при общении с теми, кто хорошо разбирается в сути, скрывающейся за терминами.

При размышлении и обсуждении задачи задействуются разные механизмы обработки и сопоставления информации. Некоторые задачи невозможно решить, пока не проговоришь описание задачи вслух, или пока не объяснишь задачу другому человеку. И наоборот, если задача не решается во время обсуждения, личные размышления могут продвинуть решение намного дальше. Творческая задача? Смени обстановку, займись другим делом между напряженными подходами к решению задачи.

Нетривиальные (тривиальность определяется только личным уровнем опыта и знаний) задачи лучше всего начинать решать загодя. Не стоит недооценивать фоновую работу мозга над задачей. Список вопросов, проблематику нужно описывать задолго до собрания, чтобы дать “настояться” идее в головах обсуждающих.

Важные решения нужно обдумывать и взвешивать несколько раз, находясь в разных эмоциональных состояниях. Так получилось, что наше представление о мире зависит от настроения.

Ретроспективная (мысль движется от конечного результата назад во времени) поверхностная (отсутствие понимания сколько было проделано работы, чтобы достичь ) оценка мешает адекватно оценивать собственные силы. Излечение возможно после собственных свершений. Поможет частое напоминание, что какими бы не были простыми и гениальными чемоданы на колесиках, придумали их относительно недавно.

Много усилий уходит на бесполезную борьбу и переживания. Бесполезными считаются те действия, которые не приближают к конечному или промежуточному результату. Помогает периодическое сопоставление действий и целей.

Фотки улиц Лимассола

Sun, 07 Sep 2014 22:45:45 +0200

В комментариях к посту ребята предложили приложить фотки. Фотки будут только из города Лимассол. Город похож на крымский поселок, разросшийся до больших рамеров. Центр существенно отличается от окраин за счет длиннейшей истории существования поселения. Фотки отражают тот город, каким я вижу его каждый день. Фото пальм, бассейнов, руин можно найти во множестве других источников.

Общий вид по направлению к центру города из tourist area

Общий вид в обратную сторону:

Улицы в tourist area (листабельно):

Пешеходная часть обычно очень маленькая. Улицы достаточно грязные. Кстати уборка улиц проводится. Очень много бизнесов закрывается, поэтому город наполнен замазанными витринами с рекламой о сдаче помещения в аренду. Так же магазины ненужных цяцек (статуи, картины, и тому подобная фигня) устраивают распродажи.

Улицы центра:

Попахивает стариной. Есть бар, расположенный в древних купальнях. На момент, когда мне его хотели показать, он оказался закрыт. На улицах торгуют ширпотребом, вином, сладостями. Встречается реклама шуб, объявляющая о себе исключительно на русском (для справки: в Лимассоле температура не опускается ниже 0 в течение года).

Мини парк, не единственный в моем районе. Чистота на улицах – не частое явление.

Вид на пляж в обе стороны с одной точки:

Пляж поближе:

Лежачок: 2,5 евро, зонтик: 2,5 евро. Маркетинг. Урны для мусора встречаются часто.

Цены на продукты на Кипре

Wed, 27 Aug 2014 19:53:21 +0200

Субъективно цены высокие. Не только по меркам Украины, но и по меркам европы. Ориентируюсь на оценки жены, которая поездила по Европе. Говядина стоит дороже свинины в полтора раза. Морская продукция представлена слабо (да-да, это на острове-то) и дорого.

Что можно накупить на 51 евро в не самом дорогом супермаркете LIDL:

UPD 01.09.2014
А вот корзина на 73 евро