-
По газонам не ходить
Не понимаю, откуда у граждан благоговение перед газонами. В их представлении газон – это особенная часть среды. Она автоматически получает защиту от любого контакта с человеком. По газону нельзя ходить, на нем нельзя сидеть. На газоне запрещено играть детям.
Если следовать правилам, то выяснится, что газон хуже асфальта или плитки. По асфальту я могу передвигаться как мне удобно, а газон нужно обходить. Только ступил на траву, как несется шиканье и неодобрительные взгляды окружающих. Нельзя же, как он посмел?
Газон становится черной дырой. Он занимает место, но с ним нельзя ничего делать. Якобы это радует глаз: ты должен смотреть и радоваться. В чем радость от того, что видишь, но не можешь потрогать? Что за фетишизм?
Страшная правда в том, что от ходьбы по газону ему ничего не будет. Попробуйте сами: пройдите в обуви по траве, прилягте, поваляйтесь. Ничего не произойдет, трава не засохнет. Все будет в точности так, как и до вас.
На этом моменте начинаются вопли о том, что один человек да, а вот если начнут ходить все, то быстро вытопчут. Нет, не вытопчут. Полный износ травы до земли возможен там, где образуются устойчивые маршруты. Например, путь от беседки до киоска. Так появляются тропинки.
Проектировщики парка или жилого квартала должны предугадать эти маршруты и сделать дорожки. Обвинять людей в том, что они ходят как им удобно – глупо. Парки, скверы и жилые кварталы строят для людей. В них должны работать правила, удобные человеку. Не должно быть проектирования только ради красоты.
В закрытой группе Вконтакте у жильцов бомбит вот по какому поводу. На пути между домом и парковкой воткнули пятачок с газоном. Люди стали срезать путь и постепенно вытоптали дорожку. Свиньи! Понаехало быдло из деревень!
Спрашивается, кто был тот проектировщик, который поставил препятствие поперек маршрута? Это жилой квартал, а не городок для малышей. Вот приехал человек с работы, устал. С какой стати он должен что-то обходить? Когда он покупал квартиру, он платил в том числе и за комфортный двор.
Когда люди ходят по газону без четкой цели, они равномерно распределяются по площади. В результате нагрузка размазывается по всему газону. Каждая пядь земли принимает незначительный урон. Трава не увядает, газон сохраняет цвет и фактуру. Самое главное: наконец-то он становится полезным.
Взгляните на фотографии европейских университетов. Перед каждым лужайка. Десятки студентов сидят, лежат, и, господи боже мой, ходят в обуви по траве. Почему-то с травой ничего не происходит. Что они делают не так?
Давайте признаем: не ходить по газону это совок. Мы слышали это в детстве от недовольных бабушек и мамаш. Нельзя без объяснения причин. На самом деле можно. Газон – часть городского пространства. Эта часть должна быть полезна человеку. Иначе от нее избавляются.
-
Общение. Идеальное окружение
Сталкиваюсь с ситуацией, когда человек хвалит вещи и технологии, которыми пользуется. Например, ноутбуком, редактором, машиной. Иногда они нарекаются правильными и единственно верными.
Казалось бы, собеседник не выгораживается – он хвалит не себя, а вещи или программы. Но долго слушать эту хвалу невозможно. Почему?
Человек это сумма того, что он потребляет. Одежда, программы, книги накладывают на него отпечаток. Наш мозг компилирует то, что поступает ему на вход, и лишь в редком случае добавляет сверху что-то новое.
Когда все в окружении человека идеально, он по инерции считает идеальным и себя. Мозгу кажется это логичным: если потреблять самое лучшее, будешь лучшим. Проблема в том, что притупляются две части мозга: критическое мышление и любопытство.
Критическое мышление различает в вещах недостатки. Натренированное мышление распознает их раньше, чем наступит разочарование. Это защитит от эмоциональной ямы, когда подведет язык, техника или другой человек.
Любопытство побуждает исследовать предмет не потому, что он идеален, а потому что просто хочется. Оно привносит элемент случайности, стимулирует интерес к жизни.
Получается забавная корреляция. Есть предметы на выбор, и есть набор, которым пользуется человек. Удивительным образом оказывается, что выбранные предметы – самые лучшие. Какое совпадение! Со стороны смотрится нелепо, но человек искренне убежден: его выбор лучший.
Нахваливать то, чем пользуешься – значит хвалить себя. Это как нейронная сеть с обратным распространением. Не предметы классные, а я классный. Что случится, если забрать все ништяки? Получится ли быть таким же классным? И как ты жил до того, как появилась эта вещь?
Перечисления, что пользуешься только этой техникой, только такой программой или только машиной того концерна означают хвастовство. Этим и объясняется то, что слушать подобные речи невозможно.
Всем хочется, чтобы их выбор был идеален, а вместе с ним и они тоже. Но так не бывает. Будет правильно отделить себя от вещей и информации. Есть все это, а есть я – не задетый этим шумом. Я смогу жить и работать, пользуясь тем, что считаю правильным.
-
Новый раздел: книжная полка
У меня новый раздел Книжная полка. Собрал на отдельной странице книги, которые прочел за последние 5-7 лет. К каждой прилагаю скромную рецензию.
Сейчас дочитываю еще две книги. Буду держать страничку актуальной.
В разное время я читал с разной частотой. Иногда по две книги в месяц, а иногда по полгода без чтения вообще. Только бульварные статьи с популярных ресурсов.
Время на чтение можно найти всегда. С некоторыми книгами нужно только начать, и аппетит придет в процессе.
Долгое время я считал, что одновременно можно читать только одну книгу. Вроде как читать еще и вторую это как изменять первой. Но теперь читаю сразу две. Когда устал от одной, переключаюсь на другую.
Читайте бумажные книги, если это возможно. Когда откладываешь прочитанный том, возникает необычное удовольствие и гордость. Этого нет в случае с электронной читалкой.
Можно верить тому, кто написал книгу, но не тому, кто толкает идеи в чатах и соцсетях.
Чтение это особый процесс, ему нет аналогов.
-
Общение. Факты и оценки
Поговорим о фактах и оценках в речи. В чем между ними разница, как правильно составить разговор и не потерять тему.
Все, что мы говорим, условно делится на два типа: факты и оценки. Факт – это утверждение, которое либо истинно, либо ложно. Факт не зависит от того, кто его высказал. Если человек не врет или его не обманули, то утверждение истинно. Если друг сказал вам, что купил книгу, скорей всего так и есть.
Оценка означает отношение человека к факту. Если книга привела вас в восторг, навеяла скуку, вызвала отвращение, то все это оценки.
Техническая литература, наука, руководства говорят фактами. Мы встречаем оценки в художественной литературе, рецензиях, колонках.
Я заметил, что люди испытывают трудности в общении, когда не различают факты и оценки. В ответ на факт собеседник отвечает оценкой и наоборот. В такие моменты разговор дает сбой. Реплики не подходят друг другу. Тому, кто начал разговор, становится трудно его продолжить.
Если обмениваться фактами и оценками без всякого порядка, беседа перейдет на повышенные тона или сарказм. В интернете это называется срач. Скорей всего, в чатах, где вы сидите, люди общаются в формате срача.
В ответ на факт дают оценку:
– Вчера купил книгу Невзорова, прочел три главы.
– Не перевариваю Невзорова, странный тип.Или речь об отношении, но нам сообщают бесполезный факт:
– Я не доверяю Невзорову. Его суждения поверхностны, он не приводит доказательств.
– Зато он написал много книг и выступает на радио.Покупка книги это факт, его невозможно оспорить. Собеседника не просили давать оценку творчеству Невзорова. Что делать с ней тому, кто купил книгу? Немедленно выбросить ее? Извиниться?
Будет правильно не реагировать на непрошеное мнение, но для этого нужна практика и контроль. Скорее всего, разговор перейдет во взаимные нападки и оправдания.
Во втором диалоге факт не может повлиять на оценку. Зачем было его высказывать? Автор первой реплики не говорил, что ценит именно тех публицистов, кто выступает на радио. И в этом случае беседа теряет нить.
Любой разговор переходит к обмену мнениями, даже если начался с фактов. Этому служат две причины: неплодотворность и человеческая натура. Неплодотворность в том, что обмен фактами банален и не дает места обсуждению. Вы сказали, что купили Невзорова. Но собеседник много слышал о нем, как же удержаться? Отвечать, что он выгулял собаку? Скучно! Проявляет себя человеческая натура. Это желание рассказать о себе, выразить накопленные эмоции. Здесь и пригодится все, что коллега прочел о Невзорове, неважно в Википедии или желтой прессе.
Переход к оценке неминуем. Как сделать так, чтобы не повисло напряжение? Достаточно вопроса, который обозначит переход к мнению:
– Вчера купил книгу Невзорова, прочел три главы.
– Интересно. Что думаешь о прочитанном?
– С большей частью согласен, но есть и спорные моменты. А ты как к нему относишься?
– Не перевариваю Невзорова, странный тип.Вопрос о мнении это граница. Она делит реплики не безопасные зоны. Сначала факты, спорить с которыми нет смысла. Затем начались оценки. Разрешены личные мнения, убеждения и предрассудки из детства. Важно, что переход из безопасной зоны в опасную произошел через буфер.
Если не различать факты и оценки, можно попасть в неловкую ситуацию. Например, не найти понимания с незнакомым человеком или охладить отношения с коллегой.
Когда кто-то рассказал историю или упомянул человека, не спешите с оценкой. Скорей всего, первая реакция будет банальной, и собеседник слышал ее сто раз. Не вываливайте на слушателей факты из википедии, если беседа не располагает к этому. Не будьте занудой и ходячей энциклопедией.
-
Читалка Kindle, продолжение
Два года назад купил читалку Kindle, написал о первых впечатлениях. До сих пор пользуюсь ей, ношу на работу, беру в отпуск. Решил дополнить оригинальную заметку плюсами и минусами, которые становятся видны только при долгом использовании.
Качество сборки не подвело. За два года экран не выгорел и не поцарапался. Нажатие пальцами на экран отрабатывает так же точно. По внешнему виду трудно определить, что читалке два с половиной года.
Нет претензий и к прошивке. Ничего не виснет, документы подгружаются без задержек, синхронизация между Айфоном и Киндлом работает без нареканий.
Если брать читалку, пусть это будет Киндл. Хоть она и стоит дороже, но цена окупается качеством и сроком службы.
Вот к каким выводам я пришел за время пользования устройством.
Читалка идеально подходит как альтернатива монитору. Сервис Send to Kindle отправляет любую страницу в интернете на устройство, удаляя верстку и рекламу. Остается только текст и иллюстрации. Читать с Киндла легче, чем с монитора.
Киндл подходит для художественной литературы. Я прочитал на нем Оруэлла и Стивена Кинга, впечатления почти как от настоящей бумажной книги.
А вот для чего Киндл подходит плохо, так это для технической литературы. Читать PDF все так же тяжело. Текст прибит гвоздями к книжной верстке, приходится часто мотать страницу или напрягать глаза. Читалка довольно умна и срезает белое поле по краям страницы, но это не всегда помогает.
Даже если вам обещают книгу в формате mobi или epub, она может быть сверстана ужасно. Об этом пишут рецензоры на Амазоне: электронная книга порой бывает днищем, а стоит не намного дешевле бумажной копии.
Неожиданно, но электронная книга неудобна в плане навигации. Я открываю обыкновенную бумажную закладку за две секунды, а на устройстве это займет десять секунд. Когда читаешь техническую литературу, нужно листать туда и обратно, чтобы сверяться с деталями. Это тоже быстрее, если книга настоящая. Если в одно и то же место возвращаешься часто, кладешь туда палец.
Читалка это довольно тугое устройство, экран показывает текст с задержками. Частая перемотка утомляет.
Бумажная книга и закладка показывают прогресс. Это мотивируют закончить книгу быстрее. На электронной читалке цифра 60% ни о чем не говорит. Бумажная книга сигналит – уже больше половины, чувак, поднажми и скорей за новую. Может быть поэтому я читаю настоящие книги быстрее.
Я обозначил следующий приоритет: лучше всего бумажная книга. На втором месте Киндл – в тех случаях, когда оригинал не найти или чтобы не читать с монитора. На третьем месте монитор, если нужно прочесть документацию, формулы или код. Со всем этим у Киндла беда. Код дробится на мелкие строчки, картинки маленькие, таблицы не влазят. Если это не художественный текст и он не был подготовлен для устройства, читать его трудно.
-
A hidden message in Cognicast podcasts
Being listening to Cognicast, a series of Clojure-related podcasts, I’ve found a funny thing. Not sure if anybody has ever mentioned it before across the Internet. Each podcast starts with a jingle sound that follows right after announcements and a long pause. And in the end, there is also another weird sound that finishes the issue.
Those two sounds are borrowed from the Gauntlet 4 video game. It is a great fantasy game where one of the four characters travels through mazes full of monsters to encounter a dragon at the end. I’ve played this game on Sega Mega Drive (Sega Genesis in the US) for a long time being a kid.
This is the first sound. It appears when a hero picks up a key:
And this is the second when a hero goes through a portal:
I may guess there is a hidden message here: before entering a podcast, you pick up a key. And finally, you exit from a maze with the victory.
The idea of that came to me when I found myself singing a musical theme from the game right after the podcast has finished. I’m not sure if I’m right, but this one is really a great message. Thanks to those guys who are responsible for audio production.
Bonus: listen to the soundtrack. I hardly can imagine it was written using primitive 8-bit midi-driver.
-
Сны-фильмы
Иногда мне снятся необычные сны, похожие на фильмы. Они насыщенны событиями, необычными сюжетными поворотами, и невозможно сказать, чем все закончится. Мне кажется это удивительными, поскольку и сценарист, и зритель в данном случае одно и то же – мой мозг. Как и другие сны, они быстро забываются, и на следующий день я уже не могу вспомнить, что там было, остается только впечатление, что только что вышел из кинотеатра.
Сегодня я проснулся в шесть утра после просмотра сразу двух таких снов-фильмов. Ощущения были столь сильными, что решил записать сюжет. Как бы ни хотелось снова уснуть, сел за ноут и начал писать. Все, что написано ниже, я увидел во сне, подправил только самые мелочи.
Сон первый. Две цивилизации
На далекой планете живут две цивилизации. Окружающая среда очень неблагоприятна, случаются бури, землетрясения, извержения вулканов. На поверхности жить невозможно, и цивилизации пошли по разному пути. Первая ушла в недра земли, чтобы укрыться от сильных ветров. Вторая научилась строить комплексы, которые парят над землей. Таким образом, каждая цивилизация и выиграла, и проиграла: под землей не страшны внешние катаклизмы, но опасны грунтовые воды и землетрясения. Воздушным комплексам не страшны сотрясения земли и вулканы, но причиняют вред бури.
На поддержание двух экосистем тратиться много энергии, жители пребывают в постоянном труде. Особая ситуация имеет место у воздушников: львиная часть добытой энергии уходит на поддержание в воздухе особого комплекса с высшим командованием. Никто не разу не видел их представителей, но все уверены, что оно решает все их проблемы. На самом деле там пребывает коррумпированная элита и олигархи, которые погрузили себя в крио-сон в надежде проснуться в будущем, когда проблемы с катаклизмами будут решены. На деньги этих олигархов существует каста своего рода жрецов или оракулов – тех, кто распространяет пропаганду и вынуждает обычных людей работать. За это жрецы, как в древнем Египте, получают большую зарплату и привилегии.
В подземной цивилизации такого нет, общество более равноправно. Им приходится работать больше, жить скромнее, но они более дружные.
В каждой цивилизации намечается протагонист. В подземной цивилизации это девушка, в надземной – юноша. Его терзают подозрения насчет командования, он задается вопросами о том, всегда ли их общество жило по таким правилам. Ему всячески препятствуют жрецы. Он начинает расследование и выясняет, что происходит. С помощью единомышленников он решается на саботаж – перевести энергию, затрачиваемую на поддержку командования, на нужды жителей, чтобы нормализовать их рабское положение. С трудом и битвами, но это удается. Комплекс командования опускается, элита под угрозой. Но жрецам удается убедить жителей, что нынешний порядок справедлив, а юноша и его подельники – террористы. Героя садят в тюрьму и приговаривают к смерти.
Начинается небывалой силы природный катаклизм. На этот раз чтобы преодолеть его, нужна колоссальная энергия. Группа жителей становится на сторону героя, понимая, что он был прав – обеспечение командования потребляет слишком много ресурсов. Героя освобождают, начинается попытка захвата центра распределения энергии. Из-за угрозы урагана комплексы воздушной цивилизации опускаются на поверхность планеты. Тем временем здания подземной цивилизации тоже поднимаются из-за проблем со сдвигом литосферных плит и водой. Цивилизации встречаются, их настроения друг к другу враждебны. Жрецы хотят сохранить свое положение и видят спасение в том, чтобы отнять у подземных жителей ресурсы. Они распространяют мысли, что на них вот-вот нападут, и надо действовать первыми. В подземном обществе вспоминают легенду о том, что когда-то обе цивилизации были одной, но затем, из-за конфликта и предательства в высшем командовании, а также нехватки ресурсов, проигравшую сторону вынудили уйти под землю.
Начинается столкновение, юноша и девушка встречаются и становятся парой. Вместе им удается остановить войну и направить усилия на совместное спасение. Два центра энергии цивилизаций соединяются, и на короткой момент они выделяют колоссальные ресурсы, которых хватает обеим сторонам, чтобы преодолеть кризис. Высшее командование раскрыто, олигархи просыпаются, над ними смеются и осуждают. Они разжалованы и занимают низшее положение в обществе.
Катаклизм проходит. Цивилизациям пора разъезжаться обратно, потому что жить на поверхности они не приспособлены. Пара хочет быть вместе, но каждый из них стал лидером своего народа. Они клянутся, что сделают все, чтобы объединить два разрозненных общества в одно. По прогнозам ученых, в следующий раз обе цивилизации смогут вернуться на поверхность только через 70 лет. Юноша и девушка обещают, что сделают все, чтобы сократить этот срок и увидеться хотя бы еще раз.
Сон второй. Охотники за воздухом
С Земли отправляют группу поселенцев на огромных, похожих на дирижабли, кораблях на другую планету. Поселенцы должны подготовить прибытие основной части населения, что по плану должно произойти через несколько поколений. Один из членов группы, молодой ученый, усердно работает и проявляет ко всему большой интерес. Работа состоит в раскопках недр в поисках особого минерала, из которого, помимо других полезных веществ, можно высвободить кислород.
Главного героя смущает две вещи. Во-первых, по его расчетам, воздуха добывается несоизмеримо меньше, чем тратиться на жизнеобеспечение группы, поэтому возникает вопрос – за счет чего его они живут и как долго это продлиться. Ему отвечают, что на самом деле кислорода добывается больше чем достаточно и все будет хорошо. Однако его расчеты это не подтверждают.
Во-вторых, во время раскопок ученый находит в грунте фрагмент электронного устройства. Его пытаются убедить, что это он же и потерял его ранее, но анализ показывает, что вещь была выпущена много лет назад. Тогда ученому объясняют, что он был прав – группа потребляют воздух из ограниченных запасов корабля, 90 процентов которого были заполнены как раз воздухом, а не техникой. Из-под земли удается добыть лишь малую толику минералов с кислородом, и таким образом экспедиция не может компенсировать его расходы.
Раскопки ведутся на том месте, где много лет назад потерпела неудачу прошлая экспедиция. По плану с Земли, именно в этом месте залегают богатые месторождения. Но природный катаклизм засыпал карьер, и никто не выжил. Из нынешней экспедиции никто не уверен на 100%, что месторождения действительно здесь. Фактически группа становится участником лотереи, где награда – большие деньги, но в случае неудачи гарантирована смерть, поскольку посылать помощь с Земли слишком дорого.
Ученый взламывает электронные архивы и изучает данные прошлых экспедиций. Среди прочих записей на него производят впечатления тайные записки девушки-ученой. Она пыталась убедить свою группу, что на самом деле месторождение, богатое кислородом, находится в другом месте. Однако с Земли пришел приказ вести работы именно там, где приземлился корабль. Девушка пишет, что виной тому могущественная корпорация, которая приказывает разрабатывать не те месторождения, что богаты кислородом, а другие, богатые металлами.
Герой проверяет данные, и все сходится – там, где они ведут раскопки мало кислорода, но много металлов. Серия экспедиций рассчитана на развитие колонии-рудника, а не свободного поселения. Он созывает группу и пытается донести факты до остальных, но капитан команды грубо обрывает его и изолирует за саботаж. Ученый догадывается, что капитан – доверенное лицо той самой корпорации с Земли.
Ученый бежит из изолятора и убеждает большую часть группы встать на свою сторону. Вместе они решают переместить комплекс на новое место. Начинается захват комнаты управления и борьба. В момент крутого маневра часть корабля с капитаном обваливается в карьер.
Главный герой становится новым лидером группы. Перед ним сложный выбор: остаться на старом месте, где есть хотя бы скудные залежи минералов, или двигаться на новое место, указанное в архивах без каких-либо гарантий. Остатков топлива хватит только в один конец.
Принято решение двигаться. Анализ горных пород на новом месте показывает, что содержание кислорода в минералах более чем достаточно. Герой втыкает лопату в грунт и говорит, что это место будет городом, названным в честь той девушки. Группа начинает усердно работать. Через 100 лет зритель видит очень развитое поселение. Оно живет автономно от Земли и намерено создать новую цивилизацию. В центре города воздвигнут постамент двум ученым – главному герою и девушке, чьи записи помогли найти место. Постамент сделан из минерала, который испаряет кислород.
Вот такие вещи мне снятся. Очевидно, что все это комбинация уже просмотренных фильмов, пройденных игр, прочитанных книг. Но все равно получилось очень складно, по современным канонам. Завязка, главный герой и его проблема, развитие, параллельная любовная линия, кульминация и развязка. Победа мужества над алчностью. Думаю, можно было бы снять неплохие фильмы по этим сюжетам.
-
Ответы на вопросы читателей Хекслета
Мне скинули ссылку на вопросы пользователей Хекслета к вебинару. Многие из них показались мне интересными, я вспомнил как задавался ими же, но не было никого кто бы мог помочь. Поэтому решил ответить в блоге. Не знаю, насколько это этично: вопросы адресованы не мне, аудитория чужая и вообще меня никто не спрашивал. Но я решил попутно провести эксперимент – отвечал быстро, почти без раздумий. Так что пусть будет. Везде сохранил пунктуацию оригинала, пропустил только то, что касается развития Хекслета и личные обращения.
Вопрос по поводу прокачки “понимашки” :)
Проблем с самоорганизацией и мотивацией нет.
Есть проблема с интеллектом и математической подготовкой: многие сложные вещи не получается переварить самостоятельно. Конкретные примеры такие: задачки из СИКПа (над большинством сижу по неделе, таким макаром я его читать буду года 3, что затормозит мой прогресс в других сферах программирования), некоторые задачи на работе (трачу очень много времени - вместо выделенных 3-х часов на таск, в итоге залогировано 9 часов).
Последние исследования говорят о том, что мозг пластичен, меняет свою структуру при развитии, но вопрос во времени и целесообразности действий.
Можно ли, используя правило 80\20, научиться прикладывать усилия в самых “нужных” местах, чтобы получить максимум возможного результата и потратить меньше ресурсов?
Ориентируйтесь не на исследования, а на ощущения: что говорит тело. Нет смысла тратить адское количество времени на СИКП. В итоге, убухав год, вы станете только одним из тех, кто прорешал весь СИКП. Таких как вы тысячи, но им по-прежнему тяжело найти работу в промышленной разработке и сделать карьеру. Насчет последнего вопроса: если я понял правильно, то да. Не обязательно прорешивать каждую проблему до самых мелочей. Для обучения достаточно понять суть и двигаться дальше, а вот уже на настоящем производстве решать задачу не на 100, а 200 процентов.
Углубляясь в профессию посредством курсов,статей или практики, определенные вещи даются хорошо, какие-то только на уровне понимания и использования (углубление откладывается на потом). Но с ходом времени, даже с минимальной практикой, то, что знал хорошо - забывается и с трудно воспроизводится даже с помощью конспектов, а отложенное для углубления - растёт как снежный ком. Причем, дело тут даже не в в самом “откладывании”, а скорее в кол-ве информации, которую нужно изучить. И такая ситуация происходит по сути на каждом уровне знаний, будь то фундаментальные вещи или продвинутые концепции.
На уровне написания кода здесь и сейчас - все более-менее неплохо, но мало о каких вещах я могу с уверенностью сказать, что разобрался в них до конца. А время идет, и нужно приступать к чему-то следующему.
Вопросы следующие: это перманентное ощущение незавершенности - это нормально? Как лучше учиться - идти дальше и все в конце концов сложится в пазл, либо пытаться “докопать” до конца? И как лучше структурировать материал/вести записи, когда информации действительно много? Может есть какие-то лайфхаки/материалы которые в этом помогут?
Ощущения незавершенности – нормально, особенно в процессе обучения. Все решения тренировочных задач незавершены, потому что это упрощение. Чередуйте движение вглубь с движением вперед. Рассматривайте мозг не как книжную полку, а индекс, который быстро направит к нужной полке. Не так важно, что вы не поняли быструю сортировку, это нужно отложить напотом и двигаться дальше.
- Здравствуйте, сейчас пытаюсь изучать Machine Learning & Data Science и в процессе изучения возникают некоторые трудности, в частности когда речь заходит о мат. анализе или статистике, приходиться во время прочтения книги или просмотра курса, углубляться в те познания которые отсутствуют или были забыты. На это уходит достаточно много времени ,так как за изучением одной темы, скрывается другая и т.д. Хотелось бы узнать какую стратегию изучения выбрать - гуглить по мере поступления вопросов или сначало набраться нужного бекграунда и после приступать к изучению данной темы. Интересно ваше мнение и как бы вы поступили в данной ситуации.
- Сейчас для изучения чего-либо, пишутся много книг, проводят разные курсы, как не запутаться во всех этих материалах и проследовать правильным путем к достижения цели?
Ответ на оба вопроса одинаковый. Все учебные материалы похожи, т.к. разрабатываются примерно по одной схеме. Правило простое – гуглите книги или курсы, берите тот, где больше звездочек. Этого достаточного для быстрого старта. Потом, чтобы опыт не выветрился, нужно затолкать себя в проект по этому направлению. Дальше вас будут учить опытные коллеги, они же подскажут материалы для продвинутого изучения.
Блокчейн (не касаясь криптовалют)- есть смысл погружаться в него? Технология войдёт в нашу жизнь, как смартфоны, или останется “игрушкой” а-ля эфир-зефир-койн?
Проблема Блокчейна в том, что он оброс толстым слоем всевозможных крипто-аналитиков, мошенников, сомнительных стартаперов. Выражение “крипто-стартап” вызывает тошноту. Скажем так – блокчейн как технология будет иметь место, но не настолько широкое, как заливают упомянутые лица. Просто будет такая технология, будут вакансии, случаи внедрения и отката. Стоит заметить, что за 10 лет Биткоина не появилось ни одного действительно полезного продукта на его базе, а это повод задуматься.
Как правильно заниматься по СИКП? Решать все задачи подряд, какие главы стоит пропускать? Заметил что между Последовательностями и Программированием, управляемым данными в книге есть немалый раздел про графическую и символьную часть.
Главное правило в том, что не нужно себя насиловать и выставлять СИКП как откровение. Это мощная книга, но вопрос в том, будет ли польза от того, что вы потратите год на решение всех задач. Мне кажется, будет лучше внимательно их разобрать. Польза будет такая же, а времени потратите на порядки меньше. Ну и за один только СИКП на работу вас никто не возьмет.
Когда по вашему мнению профессия программист исчезнет(как массовое явление)?(только честно). Ведь автоматизация в этом направлении уже идет…
Нет. В разное время их будет больше или меньше, но профессия не исчезнет, это чушь, которую несут футурологи. С такой же уверенностью можно сказать, что исчезнут врачи, лечить будут только роботы.
- Когда спрашивают на собеседовании об ООП, чтобы вы посоветовали отвечать? Классика жанра или по Алану Кею.
- ML это мыльный пузырь или тренд на десятиление? Математика была готова как лет 40 назад, инструменты с 2000-х точно (matlab, excell, python), а вот реально доступные большие данные появились с 2010-х (вернее генерация данных для бизнеса). Это ж голый матстат и линалгебра. Откуда хайп? Почему все готовы учить ML? Есть ли реальный спрос на ML или все-таки это спрос на фундаментальных математиков?
- Рекурсия. Почему многие языки так и не поддерживают оптимизацию хвостовой рекурсии?
1) Если вам позарез нужна эта работа, отвечайте по канонам, не нужно что-то доказывать. Вообще, при устройстве на первую работу полноценного мнения у вас и не может быть из-за малого опыта. Отвечайте что написано в книгах, если собеседник не согласен – не спорьте, а спросите прямо: у меня мало опыта, мне интересно ваше мнение. Это даст миллион очков в вашу пользу. Человек, который умеет слушать в сто раз полезней человека, который знает ООП. Собственное адекватное мнение про ООП у вас может быть только после 5-8 лет работы в промышленной разработке, но там и собеседование будет другое. Когда джуниора спрашивают про ООП, это скорее проверка на адекватность и базовую осведомленность.
2) Пожалуйста, не используйте слово “тренд”. Стараниями маркетологов, сеошников и прочих оно обесценилось до уровня слова “хайп”. Не хватает только банера мобильного оператора со слоганом “МТС это тренд”. Если по делу, ML займет определенную нишу. Оно уже показало, что способно решать важные задачи, поэтому будут вакансии, будут курсы. Тренд – это максималистическое, юношеское понятие (если речь не об экономике или промышленности). Кто-нибудь может сказать, что программирование на Руби это тренд? Мир быстро расширяется, и то, что вчера было “трендом”, становится просто устойчивой его частью. Можно неплохо зарабатывать обычным разработчиком сайтов безо всякого ML. Но если есть время и деньги на изучение – почему бы и нет. Помните, что после курсов нужно запихнуть себя в проект с ML, иначе все будет зря.
3) Потому что хвостовая рекурсия неочевидна даже опытному программисту. Каждый раз приходится напрягаться и определять, “оптимален” ли этот случай или нет. В императивных языках с изменяемыми переменными и циклами в ней вообще нет смысла. В Кложе специально ввели конструкцию loop-recur потому что это удобно – во-первых, сразу сигнал о том, что это хвастовая рекурсия (под капотом это цикл), во-вторых, она гарантирует жесткие проверки на “хвостовость”. В Скале требуется специальная аннотация. Словом, в императивных языках хвостовая рекурсия даром не нужна, в функциональных она должна быть явно обозначена.
Сколько оптимально выделять в день времени на труд над решением задач и изучением теории программирования, так чтобы не перегореть и двигаться более-менее эффективно?
Достаточно приходить на работу немного раньше, не читать соцсети, исключить посторонний шум. Тогда будет час времени, что достаточно на неглубокое изучение чего-то нового. Если времени не хватает, а страсть к предмету все выше, нужно переходить в проект, где с этим работают, или в конце концов отпустить это увлечение.
Что нужно делать чтобы развить soft-skills?
Нужно читать клевых ребят: редакторов, журналистов, программистов, короче всех, кто делает что-то хорошо. Потому что чаще всего они пишут как раз про сложные ситуации, которые разруливаются не по учебнику. Например, просроченный дедлайн, обострения в проекте, конфликт с заказчиком т.д. Вот там все самое нужное и написано.
Я вот на эликсиреСкулл просматриваю текст Основы. Вот что мне делать. Я вот если прочту мне просто это повторять (кодить)? Быстро запоминаются? То есть как программисты работают с документацией?
Вы можете это повторить, но без гарантий, что в голове что-то останется. Повторение без педагога не всегда эффективно. Например, я могу повторить 100 китайских иероглифов без какой-либо пользы для изучения китайского языка. Так что я не уверен, что одно только повторение даст результат.
Эликсир есть смысл учить?(не участвую в конкурсе) Или другие лучше?(Руби, Ява,…) А зачем Язык Racket изучать? С++ толк есть изучать? А язык Go?
Давайте по-честному, мы изучаем что-то, чтобы доставить мозгу удовольствие. Мы удовлетворяем любопытство – одну из глубинных потребностей нашего мозга. С точки зрения удовлетворения любопытства нет разницы, что изучать. Подойдет и любая экзотика, и промышленные стандарты. Учите что хотите! Мозг взрослого человека всегда сумеет скрестить знания из самых разных областей. Джобс ходил на курсы каллиграфии в монастыре, а через 10 лет сделал лучший по тем временам интерфейс.
как стать веб разработчиком сайты…, и нужнали для этого математика какая иммено
Нет, “веб разработчиком сайты” математика не нужна.
Скажите, пожалуйста, сколько времени в день/неделю вы посвящаете на чтение книг, статей, ведете ли вы какие-либо пет-проекты ?
Я раньше читал и пилил пет-проекты много, теперь меньше, потому что дети. Этим летом планирую снова читать больше. На самом деле все зависит от желения, а не от времени.
Используете ли вы язык Go в разработке? Какие плюсы у этого языка, и где он находит применение?
Плюсы в простоте, высокой производительности, быстрому старту, изначальной ориентированности на сетевое программирование и распараллеливание задач. Применяется для командных утилит, микро-сервисов, сетевых программ. Поддерживается Гуглом, очень популярен в Китае. Из минусов – убогая система типизации, нет дженериков (общих типов, например “любое число”), бедный тулинг (система зависимостей).
heroku, firebase, gitlab и прочие сервисы - надо/не надо, как использовать, best practice
Очень поверхностный вопрос. Любой сервис можно использовать эффективно, если знать как. Короткий ответ – читайте документацию, в ней очень много полезного.
Добрый день. У меня к вам несколько вопросов:
- Какие нерешенные задачи есть сейчас в программировании как в профессии?
- Какие неочевидные риски ожидают человека при выборе профессии программиста?
- Какие типовые ошибки совершаются при входе в профессию?
- Каковы прогнозы по появлению новых направлений в программировании?
1) Для меня наболевшая проблема – неинформативные сообщения об ошибках, когда что-то не запускается. Почти ни одно сообщение невозможно понять, только поиск в Гугле.
2) Непонимание того, что в программировании много переговоров с заказчиком. Что вокруг одной строчки может быть обсуждение в несколько дней и десятки писем. Что в 9 случаев из 10 вы редактируете чужой код, а не пишете свой.
3) Думаю, все то, что следует из предыдущего пункта. А еще излишняя самоуверенность и презрение к чужому коду и языку.
4) Что-то на стыке технологий: программирование квантовых систем или нано-машин как это показано в игровой серии Metal Gear. По сюжету, в тела солдат внедряются микрочастицы, которыми можно управлять совокупно, например, подавлять боль, эмоции, контролировать доступ к оружию или территории.
Сейчас в сети можно найти много литературы по компьютерным и математическим темам , переводов иностранных авторов, которые издавались в СССР в 70-80-90-х годах. Некоторые из этих книг, например Алгоритмы + структуры данных = программы Н.Вирта рекомендуют почитать, даже несмотря на возраст книги, мол они действительно полезны в плане развития профессионального кругозора, особенно для начинающих программистов.
Вопрос такой - стоит ли читать такую литературу, именно для развития профессионального кругозора, чтобы просто самому больше узнать не только больше о программировании но и об истории этих наук, так сказать как это всё развивалось и как мы пришли к тому что имеем сегодня? Может просто показаться что эти книги старые, неактуальные, безвозвратно устарели и нет смысла в их прочтении.
Стоит, если это приносит удовольствие. Насиловать себя смысла нет. Удовольстве будет, если вы уже знаете материал и читаете книгу как подтверждение того, что вы крутой. Тогда читать будет ненапряжно. Гораздо хуже, если вы читаете через силу и вдобавок пишете об этом во все чаты. Вспоминается сарказм: если ты бегаешь по утрам, но никто об этом не знает, это не считается.
Продолжали бы вы заниматься программированием и обучать, если за это не получали денег?
Если абстактно – нет, деньги это неотъемлемая часть качественного труда. Если в реальности, я бы нашел способ получать за это деньги.
говорят что профессия программист для молодых после тридцати ты никому не нужен какой бы гуру ты не был, потому как можно взять молодого и ездить на нем
Абсолютная чушь, в тридцать только начинает появляться опыт. Всем моим коллегам по 30 с чем-то лет, у всех проекты. Другое дело, что возраст должен кореллировать с уровнем. Искать работу джуниором в 30 лет весьма сомнительно.
Расскажите, пожалуйста, каков, в вашем видении, должен быть процесс роста front-end разработчика после Middle-уровня. Я конечно, понимаю, что это все размытые понятие, и в разных компаниях это может обозначать кардинально разный уровень навыков и самостоятельно решаемых задач, но все же - какой путь развития выбрать после 2-3 лет в индустрии (хотя это уже наверное что-то между senior и middle будет)? Дальше развивать свои навыки, расширять стек и улучшать качество кода, становясь полноценным Senior? Подтягивать back-end (ту же ноду, например) и брать курс на full-stack разработчика? Или же плавно перекатываться вообще в менеджмент? Или архитектура?
Я понимаю, что направления разные и нельзя однозначно сказать, что одно лучше другого, но интересно, какие бы вы могли дать рекомендации относительно каждого из них, плюсы-минусы, а если еще и своим опытом поделитесь - вообще будет прекрасно:)
Я не уверен, что после Middle-уровня пора уходить куда-то в сторону. Нужно замечать, что оказывает влияние на конечный продукт – и довольно быстро выяснится, что все. И бекенд, и менеджмент. Невозможно сказать точно, что именно вам понадобится, так как это зависит от конкретного продукта. Просто берите больше ответственности и действуйте по ситуации.
Я достаточно апатичный человек. И это сильно мешает по жизни. С одной стороны, очень хочется выполнять работу в срок, дописать несколько начатых программ, всё успевать. Но с другой стороны, всё время заваливаю сроки, отвлекаюсь на мелочи и просто хандрю :-( Пытался составлять список дел, не хватило собранности ему следовать. Мне 22 года, учусь в университете по технической специальности. Есть опыт работы после колледжа. Как по Вашему опыту, есть выход из ситуации? Что посоветуете? И присоединяюсь к вопросу о soft-skills.
Нет, вы не апатичный человек, во просто нацепили на себя где-то услышанный термин. Думаю, будет достаточно ничего не делать с неделю, отдохнуть от компьюрета, соцсетей и чатов, создать вокруг себя вакуум. Найти хорошую мотивацию или ментора\учителя. Просто двигаться по программе и получать удовольствие от ее выполнения.
Как вы боролись в ActiveRecord в своем проекте, бодрые советы как не создавать божественные модели (PHP Yii, Laravel)
Не знаю, как это делается в указанных технологиях, но попробуйте поработать с сырым SQL с минимальными обвязками. Постепенно придет понимание, как лучше устроить работу с базой.
Как обьективно оценивать время для решения той или иной задачи и не впасть в крайности? И еще один очень важный вопрос - возможно ли эмоциональное выгорание в профессии программиста, из-за чего оно происходит, как решать?
Есть нехитрое правило – взять первую же оценку и умножить на два. Например, если кажется, что сделаешь задачу за день – бери два. Выгорание возможно по многим причинам, в том числе из-за проблем на уровне команды. Поможет отдых, разговор в непринужденной обстановке. Иногда нужно отпутсть цель, которую достичь будет слишком дорого. Иногда проще сменить проект. Все зависит.
Виртуальная реальность сейчас - это как интернет в прошлом? Что вы думаете о перспективах развития этого направления?
Мне кажется, VR будет связан с сексуальной темой – реалистичной порнографией и имитацией секса с воображаемым партнером. А может, и настоящим – при работе устройств в паре или по сети. Добавьте сюда материалы для имитации кожи, запахи, звуки, воздействие датчиков на эрогенные зоны, в общем – картина ясна. Тому способствуют два фактора. Первый – VR это технология исключительно для развлечения, ни к чему другому ее нельзя применить. Второй – никто не видит, что происходит у вас на мониторе. Все сходится.
Брался за программирование несколько раз в своей жизни, но всегда бросал. Проблемы были из-за мнений других людей. Допустим, негативный комментарий к коду на сайте про IT-тематику, который мог бы написать я (статья и код не мой, просто похожий образ мыслей) мог выбить меня из колеи на несколько месяцев. И всё в таком духе. Из-за этого боязнь задавать вопросы и т. д. Может быть, вопрос не по адресу, но что делать в такой ситуации? Спасибо.
Это проблема широкого плана. Главное понять, что комментарии относятся не лично к вам, а коду, который можно исправить. Еще помните, что в интернете нет баланса между положительными и отрицательными отзывами: можно собрать тонны ненависти за кривой виджет и ни слова похвалы за работающий в целом продукт. И вообще, слушать нужно только нескольких авторитетных для вас людей, мнением остальных полезно пренебречь.
Как не просто быстро, а супер быстро прокачивать скилл и ex. в разработке?
Запихать себя в проект с упором на то, что вы намерены прокачать.
Где можно найти достоверные толкования терминов программистких? И онлайн словарь Eng - Rus достоверный?
Достаточно спросить у коллег.
Как Находить проблемы которые нужно решить в программировании? В вебе.Или в фрейворках .Или как то еще. Задачи. На чем практиковаться.
Достаточно собрать отзывы пользователей вашего продукта в свободной форме. Работы хватит на несколько лет.
Что уже не нужно знать?( к примеру фронтендеру верстку?) Или что не так важно знать в программировании вообщем? пример - не нужно выполнять какие-то действия не из-за их простоты, а из-за того что они под капотом, и снаружи облегченное использование (н/р рельсы). Или полностью автоматическое …?
Я не знаю, есть ли что-то, чего не следует знать. Наверное, из чего делают колбасу? Если серьезно, любое упрощение подразумевает, что вы знаете, как устроен процесс. Уверенность в том, что это или то знать не нужно, может вас подвести. Утверждение звучит еще более нелепо, если речь идет о карьерном росте, который наоборот подразумевает рост ответственности и кругозора.
Как справляться с перегоранием, которое появляется из-за тупикового состояния, которое появляется в результате того, что упираешься в проблему, которую самостоятельно не получается решить (либо освоить что-то)? (Почти все начинания притормаживаются на 50% пройденного пути, продолжаются с новыми силами через месяц-три, либо вообще остаются заброшенными).
Повторюсь, нужно отдыхать, даже когда очень хочется засесть и фигачить код всю ночь. Не нужно ставить невыполнимых задач. Нужно уметь отпустить цель. Всякое знание закреплять на практике в реальных проектах.
С++ нужен для фронтенда? Как считаете он будет для веба популярен? И каковы перспективы ВебАсембли?
Не нужен, не будет. Насчет Веб-ассембли – не хотелось бы впадать в пространную аналитику. Потребность в нем есть, написано очень много JS-кода, который не хочется выбрасывать. Что-то из этого будет.
Добрый день . не подскажите ,я являюсь системным администратором и хотел бы переквалифицироваться. но глядя на все это со стороны “чайника” вижу и понимаю .что это пучина , озеро в которое бухаться очень страшно и непонятно с чего начинать , дак я о чем . подскажите с чего можно начать программирование ( преимущественно думаю выбрать php/javascript\html5) заранее спасибо.
Достаточно прочесть книгу по любому промышленному языку программирования, посмотреть уроки, пройти задания. Потом как-то попасть в проект на этом языке, хоть джуниором, хоть стажером.
Вопрос про участие в опенсорс проектах, стоит ли начинать новичку, какие плоды это принесет, как и с чего начать, и участвуете ли вы, если да то в каких? Спасибо!
Моя практика показала, что нет смысла соваться в опен-сорс без навыков закрытой коммерческой разработки. Опен-сорс сообщество порой ожидает опытных разработчиков. Это среда, в которой никто никому ничего не должен, и для начинающих это скорей вред. Мой совет – поработайте несколько лет в закрытом стиле, когда код только в репозитории заказчика. Только потом появится понимание, зачем вообще нужен опен-сорс.
Плоды это приносит хорошие, например, если вы автор популярной библиотеки, собеседование сводится к формальностям.
Какие, почему и на каком уровне языки стоит изучить для максимального расширения кругозора? Какие языки изменили ваше представление о программировании или даже образ мышления?
В моем случае это стала Кложа после 8 лет классических ООП- и императивных языков. Я со студенческих лет увлекался различными лиспами, но Кложа стала поворотным моментом. Замечу, что никакой перемены бы не было, если бы я не поменял работу на ту, где писали на Кложе. Так и осталась бы игрушечными проектами на Гитхабе. Отвечая на вопрос: неплохо развивают функциональные языки без лишних усложнений, это Clojure, Racket, Erlang, Haskell. Не Scala.
Как развивать в себе ментальное программирование? Посмотрел доклады, понял к чему нужно стремится, а как это сделать не понял.
Достаточно мысленно поделить проект на множество систем и группировать код согласно этому правилу. У вас есть подсистема авторизации, только она знает как это работает. Остальным модулям запрещено нырять в ее кишки, а только вызывать высокоуровневые функции. То же самое с обработкой оплат, блокировками пользователей и т.д.
Можете вспомнить и рассказать свой распорядок дня, когда нашли первую работу разработчиком?
Я работал много, без праздников и выходных. Еще нужно со всеми здороваться, причем первым. Побольше слушать тех, кто непосредственно влияет на твое обучение, и поменьше – случайных посторонних. Пользоваться возможностями, которая дает фирма: ездить на конференции, посещать семинары.
Есть много понятий: парадигмы, архитектуры, паттерны/шаблоны, методологии… Можно ли выстроить все понятия в некую структуру, чтобы видеть картину в общем: что есть что, для чего нужно и как все это между собой связано? Например, для чего нужен SOLID, для чего TDD, для чего ООП, что есть общего у этих понятий, в какой последовательности учить?
Паттерны хороши тем, что задают некий уровень и дисциплину. Например, в проекте принято решать проблему этим патерном, и никаким другим. Это лучше, чем вечный срач в команде. Чтобы связать все паттерны в единую структуру, нужна долгая практика. На самом деле это приводит к пониманию того, что паттерны – очень условная вещь, и группе специалистов порой проще договориться и писать код так, как удобно им. Но для начинающих лучше прочесть паттерны и отвечать на собеседованиях то, что хотят услышать наниматели.
Какие сервисы и сайты в интернете можно посоветовать новичку, для прокачки своего программирования и связанных навыков?
В дополнение к своему среднему или высшему образованию, которое он сейчас получает, так сказать. Здесь можно говорить о многом, например сайты с задачами, форумы, группы в соц.сетях, каналы в telegram и т.д. Это всё конечно можно найти в том же Интернете, но новичок зачастую не знает, что ему действительно нужно и с большей вероятностью будет распыляться, всё искать что то новое. Вот например необходимый минимум, зная который он может искать что то новое, что нибудь такое хотелось бы услышать на вебинаре.
Если этот вопрос интересен, я мог бы вам написать, какие сайты и паблики использую сам, но всё таки считаю что там есть кое что лишнее, пока ненужное мне, но всё же изредка я туда захожу.
Ну, Хекслет хорош. Новичку гораздо полезнее будет группа опытных коллег, а не форумы.
Здравствуйте! В последнее время у меня в голове крутится этот вопрос, особенно перед сном. Вопрос на мой взгляд достаточно непростой и связан скорее всего, я так думаю с образом нашего мышления. Вопрос: Как научиться достойно и качественно продавать свои знания? Как научиться ценить свои знания? Спасибо.
Хороший вопрос, и не только знания, а вообще – труд. Мы думаем об одной сумме, но в последний момент смущаемся и занижаем, пугаясь насмешек, неодобрения. Думаю, достаточно будет один раз набраться смелости и назвать ту цену, которую хотели изначально. Самое страшное – заказчик предложит немного меньше. Но гораздо чаще он соглашается, потому что даже то, что вы потребовали изначально, было для него дешево.
Есть на хабре интересная статья под названием “Опасности обучения на Java” Если очень кратко, то суть сводится к тому, что сейчас “порог вхождения” низок и слабая “общая база”. Алгоритмическая подготовка, математическая подготовка и т.д. Далеко ходить не надо. Подтверждение этому курсы на каждом углу вроде “Стань Java программистом за три недели”. Вопрос прост и сложен одновременно: что поможет кодеру быть программистом? Как найти то, что будет полезно на этом пути? И кто может в этом помочь.
У любой популярной технологии низкий порог входа, это не вина Джавы. Будет полезно решать проблемы на уровне проекта, взаимодействовать с заказчиком, находить баги в верстке, побуждать смежную команду улучшить дизайн, брать в разработку сложные задачи и пр.
Хотелось бы чтобы затронули немного вопрос про мотивацию, допустим как себя мотивировать кодить, выполнять таски и в этом роде. Бывает такие моменты когда “штурмуешь” одну задачку несколько дней и падает мотивация дальше делать курсы, ведь подглядывать задачки не ок, а если начнёшь смотреть решение, то за одной задачкой и сразу другая последует. Хотелось бы ещё узнать планируются ли курсы по TypeScript, Angular2 + версии, Vue. Хотелось бы ещё побольше рекомендованной литературы, может какие книги посоветуете для саморазвития, которые можно почитать в свободное время от кодинга. Например Правило 10x. Художественная литература тоже приветствуется.
Мотивировать себя особо не нужно, изучение должно быть в удовольствие. Если задача не поддается за осмысленное время, нужно обращаться за советом к коллегам или сообществу. На практике вам никто не позволит сидеть над задачей три дня в ожидании, когда же вы наконец ее разрешите.
Недавно заинтересовала тема “депривации”, т.е. временное (или нет) лишение определенной потребности в чем-либо. Например, недавно я пробовал не спать 2 дня. Получил опыт и узнал о себе что-то новое. Также в этом году планирую временно лишить себя зрения на 10 дней, думаю будет интересно. Буду продолжать делать подобные тесты над собой и дальше. Например, сегодня перестал есть соль и сахар (для меня это не легкий шаг). Таким образом, можно придумать себе какие-либо ограничения для эксперимента или профилактики.
Зависит, извините, от вашей упоротости. Не спать два дня – вредно. Не пользоваться зрением 10 дней – имеет смысл если вы пишете книгу про слепых или снимаете фильм о слабовидящих, то есть пытаетесь вжиться в образ. А так зачем оно вам? Не есть сахар хорошо, а вот соль нужна в малых количествах. Периодически лишать себя чего-то полезно, но у вас полный разброс. Это скорее баловство, и я не вижу смысла.
Как стать архитектором?
Нужно сделать несколько проектов, где вы будете не только писать код, но и заниматься деплоем, проектировать связи между подсистемами, разрешать проблемы блокировок, производительности, масштабирования. Тогда можно писать в резюме – архитектор. Кстати, архитектор – это своего рода приманка в крупных фирмах. Я знаю много разработчиков, которые решают архитектурные проблемы, но числятся просто девелоперами. Все зависит, до чего вы договоритесь с заказчиком.
Кирилл упоминал не раз что не стоит о себе говорить как о Java-разработчике или python-разработчике, а надо говорить что мол инженер. Что делать в таком случае если в вакансиях стоят конкретные требования а-ля 5 лет опыта в js или Obj-C, как убедить работодателей что переход на другой язык дело месяцев максимум?
Чтобы удовлетворить рекрутеров, пишите в резюме одно, а в разговоре с коллегами говорите другое. Хотят они увидеть сеньора – впишите его. Не вижу конфликта. Переход на другой язык – это не дело месяца. Формально вы пишете другой код, но мыслите старыми парадигмами. Я бы не утверждал столь категорично.
Как нащупать свою нишу для создания IT продукта? Хочу рано или поздно запустить что-то свое, но пока ввиду отсутствия опыта и достаточного кругозора непонятно, как откопать что-нибудь интересное, какую-то острую для отрасли/профессии проблематику.
Трудно советовать, потому что у меня нет собственного по-настоящему успешного проекта. Мне кажется, он должен быть о том, что интересно лично вам. Например, один чувак забыл флешку когда сел в поезд. Он взбесился и написал то, что потом стало Дропбоксом. А меня бесит читать новости с сайтов, поэтому все, что я пишу в свободное время, так или иначе связано с RSS. Как-то так. Любите игры – делайте сайт об играх, о котиках, и тд.
По какому пути, по вашему мнению, стоит идти при разработке своего проекта:
-
Помимо необходимых HTML, CSS, JS освоить как можно больше технологий (Back/Front фреймворки [Django, Vue], базы данных, Nginx, Git, Webpack, Ansible, Docker и пр.), чтобы потом, как говорится в мультике «Лучше день потерять, зато потом за пять минут долететь» и к тому же меньше переделывать в дальнейшем?
-
Или же для начала сделать что-то простое с помощью нативных возможностей и имеющихся навыков, чтобы оно уже хоть как-то работало, индексировалось поисковиками, а потом по мере набирания опыта уже совершенствовать и дорабатывать?
Второе. С помощью минимального набора технологий выкатить что-то простое, начать продавать, потом улучшить.
какие методы и инструменты существуют для проверки отдачи от фич на недавно стартанувшем приложении? как решать какие фичи отбрасывать, а какие реализовывать и проверять?
Надо внедрять фичи, которые приносят больше денег.
что рассказать на вопрос про ООП на собеседовании?
Уже было выше – не надо отсебятины, рассказывайте то, что написано в Википедии и книгах. Если собеседник не согласен – послушайте его точку зрения. Заодно разведаете обстановку в фирме.
Как победить закостенелось в команде из разряда “мы всегда так программировали”, когда это явно приносит не самые плохие, но далеко не выдающиеся результаты? И отсрочка проблем вида “сейчас некогда, потом поправим”, а потом никогда не наступает.
Никак, потому что это означает менять не код, а мышление людей. Это может быть слишком дорого. И потом, для проекта это может быть оптимальный вектор развития. В сети полно историй успеха, когда X переписывали на Y и все было круто. Но гораздо больше случаев, когда это кончалось фейлом. Проверьте, насколько успешно вы внедряете фичи, насколько держитесь графика. Возможно, проблемы можно подтянуть не сменой языка, а улучшением атмосферы в проекте, реорганизацией графика релизов и тд.
-
Environ variables are not for configuring software
The recent project I’ve finished and deployed gave me a strong understanding why using environment variables for configuring is a bad idea. Briefly, I’m going to not use them anymore for setting up my software and maybe clean them out from my previous projects. There is a pile of reasons for that.
Generally speaking, env vars aren’t bad in general. I’d just like to highlight that they come from the ancient Unix time when people didn’t have suitable development tools. But nowadays we have some. For example, thanks to JSON or YAML, we do not need to parse integers or floats manually. The same about arrays or maps. Some better formats like EDN even provide built-in date support or even custom tags to parse special values. With these great tools, there is no need to roll back for 20 years ago and parse text chunks once again. That’s the routine we’ve successfully passed.
In short words, a config is usually a structured data. And we’ve got stuff to read data from text without any problems. Why use env vars then?
You might be a bit wondered reading this since it conflicts with the third section of 12 Factor App Development Manifest. This section clearly says:
The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.
Well, I read this paragraph a number of times but still guessing is there any sense out here. Easy to change? Well, you’ll need to edit some file or config anyway. Little chance to commit them into a repository, really? If you have an
ENVfile with 30 variables, there is no any difference between it and any other file in your repository, say “config.json”, “settings.prop” or “params.conf”. ENV file is just yet another file without any special properties. You still need to control by your own whether it should be ignored or tracked by your repo.The whole #3 section says nothing about what benefits the env vars bring into a project. From my prospective, since the 12 Factor App was initially written by Ruby programmers, there is nothing else then just a cargo cult.
The idea of getting rid of a regular JSON, YAML, Java .props config file is totally wrong. Of cause, if a program requires one or two arguments, there is no a reason to distribute a separate config file. Especially when those parameters have default values and might be overridden by command line arguments. But the problem is, our modern web apps require up to 30 parameters at once and even more.
Definitely, you’ll keep them in a text file, say “ENV” or “vars”. So what’s the difference here to have a JSON file?
If you take cprop, a Clojure library that turns env vars into a map, you’ll see that it provides a bunch of tricky rules for types coercion and splitting nested values. For example, “true” and “false” strings will be converted to a boolean value. A variable with a double underscore will be read as a nested map:
export FOO__BAR=42{:foo {:bar 42}}That tricky logic may let you down sometimes. Imagine you’ve got a secret API key for some service that it a string but consists only of numbers:
export API_KEY=123123123In Clojure, the result would be a number, not a string:
{:api-key 123123123}There won’t be any error during parsing, but suddenly, in the middle of running an app, you’ll get an exception that says something like “the Long type cannot be cast to a Char Sequence”. It’s because the code tries to act on that API key like it’s a string, but it’s an integer.
You should have marked that key with double quotes instead:
export API_KEY='"123123123"'Well, that’s a known issue and it’s even mentioned in the official readme, but still. I can never remember the proper order: single-double or vice versa. I don’t want to fight with those damned quotes again. It has been enough in shell scripting: single quotes, double quotes, back-ticks. Now again in my Clojure? No way.
In terms of
cprop, there is nothing weird here because it doesn’t know anything about the variable’s semantics. They are all just text and nothing else.I’d like to stress that we’ve just invented our own system of rules and wrote plenty of code just for one purpose: to turn env vars into a map. It’s plain to see the code behaves a bit strange and forces us to keep that ugly scenario with quotes in mind.
Even a dull JSON file that supports a limited number of hard-coded types seems to be a salvation after been using env vars for a long time, really. A string will always be a string and won’t turn into a number. There is no need to add a double underscore in the middle of a name to simulate nested data.
But the main reason for getting rid of env vars is they tie us to all that legacy that our systems still need to carry. Let’s say honestly, env vars are just another part of Unix shell and related stuff. I do not have anything against them when they are used in the right way. For system administration, for example, but not for web development.
I mentioned before that a program should never rely on shell commands. Never call
mkdir,curlor any other commands. You may think it reduces the code, but in fact, it’s a deal with the devil. Java code that creates a folder will work on any OS or device as expected. But a shell command won’t.The same I may say about env vars. They are part of a shell system and that’s why are great for OS environment, but not a web application. They should never affect an app running in production. The codebase should rely only on its own resources. From the app’s prospective, a JSON/EDN config file is something that an app may control. But the env vars are not.
I think that’s enough said on the subject. Provide your own config based on any structured file format, no matter if it is a JSON, YAML or EDN file. But leave the env vars alone. They are from Unix legacy and have nothing common with modern development.
-
Емакс и парное программирование
У ребят, пользующихся старыми редакторами вроде Вима и Емакса, есть дурная черта: без просьбы на то указывать, что ты не пользуешься нужными хоткеями, не ставишь правильные плагины, твои действия не оптимальны, скачай это, поставь то. У тебя это занимает три кнопки, а у меня одна. Видишь, какой я крутой?
Такое неминуемо возникает из-за того, что не существует двух людей с одинаковым конфигом, у каждого что-то подпилено под себя. Ввиду сложности программ вероятность, что вы с коллегой что-то делаете одинаково, равна нулю. Ни одна голова не вместит в себя все способы навигации по структурированному файлу. Физически невозможно перебрать все хоткеи и выбрать оптимальные по длине и физиологии.
В результате все работают по-разному. Казалось, почему бы не свыкнуться с этим фактом? Но в парном программировании просыпается какая-то детская черта “или по-моему, или никак”. Пока ведущий программист пишет, ведомый следит за мелочами и начинает травить мозг: вот здесь ты не оптимально перешел, вот тут мог бы сделать быстрее. Совершенно минуя тот факт, что у ведущего разработчика в голове огромный контекст и ни в коем случае нельзя отвлекать его внимание на такие мелочи.
Я пишу это в грубой манере, потому что сам так поступал и не вижу этому оправданий. Это плохо. Все замечания к владению редактором нужно вносить очень осторожно, только если попросят или ситуация к этому располагает. Но никогда не на середине кодинг-сессии. Хуже этого ничего быть не может.
Подам пример первым: последние дни я работаю в паре, и когда вижу, что коллега работает иначе, просто молчу. Спросят – посоветую, не спросят – значит, ему так удобней, не мое дело. Если оценивать беспристрастно, львиная часть времени уходит не на набор кода, а обсуждение и эксперименты в консоли. Грамотная навигация в лучшем случае выиграла бы минут 15-20.
Сегодня я насоветовал, не поинтересовавшись, хотелось ли коллеге услышать мое мнение или нет, а завтра я ведущий программист в другой паре, и напарник сыпет рекомендациями, какие плагины поставить. Невыносимо.
Умеешь Вим или Емакс – умей молча. Уважай других.
Ivan Grishaev's blog
Writing on programming, education, books and negotiations.