Блог Хекслета

Cиндром самозванца – это реальная штука, и он поражает новых разработчиков. Мы проходим через туториалы, буткемпы или даже полноценное университетское образование, но всё равно стесняемся делиться своим кодом. Мы боимся плохой оценки качества нашего кода. Никто не страдает от этого сильнее разработчиков с самообразованием. Поскольку у нас нет «фактического» или «задокументированного» опыта или мы не стажировались, мы оцениваем свой код ниже среднего.

Несколько месяцев назад я был таким. Я перечитывал Test-Driven Development With Python Гарри Персиваля. Несмотря на то, что всё делал по книге, я стеснялся делиться своим кодом. Пусть моё приложение и работало так, как было задумано, я не хотел делиться прогрессом. Я не хотел, чтобы кто-то указал мне на какую-то очевидную ошибку, на которую я не обратил внимание. Я хотел, чтобы мой продукт приносил удовольствие другим людям, но не хотел, чтобы они видели, насколько я слабый разработчик.

Я отложил свой проект, и после недолгой паузы стал просматривать другие проекты на GitHub. Я нашёл несколько, у которых был маленький значок на страницах README.

Как настоящий чайник, я подумал, что это просто картинка, которую Линус Торвальдс выдаёт на флешке, когда вы заканчиваете школу "Настоящего разработчика". Мне ни разу не приходило в голову щёлкнуть по ней. Я думал, что это статическая картинка, размещённая где-то в репозитории. Позже я наткнулся на проект, который показывал, что билд провалился.

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

Я размышляю о последствиях «неправильной абстракции». Мой доклад с RailsConf 2014 «all the little things» включал раздел, в котором я высказала такое мнение:

дублирование значительно дешевле, чем неправильная абстракция

А заключение я подытожила советом:

выбирайте дублирование вместо неправильной абстракции

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

This, a million times this! “@BonzoESC: “Duplication is far cheaper than the wrong abstraction” https://twitter.com/pims/status/442010383725760512

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

CSS тоже развивается, и скорее всего Houdini совершит новый прорыв в CSS, но его, к сожалению, адаптируют далеко не все. Мы всё так же проходим процесс совещаний специалистов, которые создают новые спецификации и всё такое… Не так, как с непрерывными изменениями стандарта TC39, но всё же.

Вы вероятно слышали но, скорее всего — нет! о единицах измерения в CSS, речь о которых пойдёт в этой статье. И нет, не о тех, «старых» vw и vh (которые предстоит объяснить тем, кто меньше разбирается в CSS).

Ниже перечислены новые единицы CSS, которые будут детально описаны в готовящемся CSS Value и Units Module Level 4.

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

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

В конце 50х Джон МакКарти стал всё сильнее интересоваться штукой, которую называл «Искуственный Интеллект». Он также занимался консалтингом, и благодаря этому он познакомился с SAGE air defense system: большой системой огромных компьютеров, подключенных к радарным станциям и соединенных между собой. У них был графический дисплей с указательным устройством.

Реакция Джона была «Такая штука будет в каждом американском доме». Он понял, что сеть компьютеров — это по сути «информационная коммунальная услуга» (как вода, газ и т.д.)., и что домашние терминалы могут предоставлять разные виды «информационных услуг».

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

Изучающие программирование часто удивляются: почему функция «возвращает» результат? Почему именно такое странное слово — «возврат»? Как будто мы сначала даём ей результат, а потом она его возвращает обратно.

Понятно, что это не так. Мы даём функции аргументы (а иногда и вообще не даём ничего), а она даёт нам в ответ какую-то информацию… А иногда не даёт! Тогда мы говорим «она ничего не возвратила».

Странно!

Дело в том, что return означает не возврат информации, а возврат управления.

При вызове функции текущий код становится на паузу и передаёт управление в функцию. Функция делает свои дела и возвращает управление в то место, где происходил вызов. И заодно может отправить какую-то информацию туда.

Что за управление? Управление той штукой, которая исполняет код. Грубо говоря — управление компьютером. Код передаёт функции пульт управления компьютером, а функция потом возвращает его обратно.

const sum = (a, b) => {
  const answer = a + b;
  return answer;
}

Мы привыкли читать подобный код как «функция возвращает значение answer», но правильнее будет читать «функция возвращает управление в место вызова и отправляет туда значение answer».

Именно поэтому внутри функции возможен такой код:

...
  return;
...

Здесь функция не «возвращает ничего», а «возвращает управление в место вызова и не отправляет туда никакую информацию».

Конечно, такая формулировка хоть и технически более корректна, в реальной жизни нет смысла отказываться от «возвращает значение». Это, можно сказать, общепринятое сокращение.

CSS Grid — это новый способ создания макетов в интернете. Впервые полноценная система вёрстки доступна прямо в браузере, что даёт массу преимуществ.

Эти преимущества становятся особенно выразительными, если вы сравните CSS Grid с самым популярным фреймворком Bootstrap. Вы можете не только создавать макеты, которые раньше были невозможны без JavaScript, но ваш код станет легче поддерживать и понимать.

Давайте посмотрим на три главных причины, почему я думаю, что CSS Grid превосходит Bootstrap.

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

Вот список плохих ситуаций, в которые я попадала, и как я в итоге смогла выбраться. На простом языке!

Ой, блин, я сделал что-то не то. Тут же есть машина времени, правда?..

git reflog
# ты увидишь список всех действий во всех ветках
# у каждой есть индекс HEAD@{index}
# найди тот, после которого ты все поломал
git reset HEAD@{index}
# волшебная машина времени

Блин! Сделал коммит, но понял, что забыл одну мелочь

# сделай что хотел
git add . # или добавляй файлы по одному
git commit --amend
# теперь измени или оставь старое сообщение коммита
# теперь твой последний коммит включает то новое изменение!

Это перевод статьи Грэма Ли Falsehoods programmers believe about programming.

• Моя работа не оказывает этическое влияние: я создаю технологические системы и то, как другие их используют, зависит от этих людей.
• Софт — абсолютно техническая дисциплина
• К компьютерному программированию существует своеобразная врождённая предрасположенность, ему невозможно просто научиться.
• Позволить программировать людям, которые не такие как я, можно только путём «понижения планки».
• Компилируемые языки программирования всегда быстрее.
• Вычисления с плавающей запятой приводят к недетерминированным ошибкам в числовых результатах.
• Ок, они иногда приводят к ошибкам в числовых результатах.