Программисты любят компактный код. Если он реализован грамотно, то такой код легко читается и не содержит частей, которые заставляют думать о нем больше, чем нужно.
Есть такой код, который я называю "код, который заставляет себя переписывать". Этот код не выглядит плохо и про него нельзя сказать сразу, что он делает что-то плохое. Проблемы проявляются позже — в тот момент, когда нужно внести изменения либо отладить его.
Изначально этот материал планировался, как урок в PHP курсе по полиморфизму. Но он, в конце концов, перерос сам урок, и я решил сделать из него отдельную статью. В ней практически ничего PHP-специфичного, поэтому рекомендуется для прочтения всем без исключения.
Традиционные инструменты, используемые до REPL в PHP - это var_dump()+die() и XDebug. REPL (Read, Execute, Print Loop) - новый инструмент, позволяющий сделать этот цикл более удобным, интерактивным и быстрым. Во многих языках и теперь и в PHP он реализован как командная строка, которая получает код, по необходимости принимает ввод от пользователя, выполняет код и сразу же выводит результат выполнения.
Ниже представлена подборка типичных ошибок, которые допускают программисты при именовании переменных и функций в своём коде. Примеры взяты из проектов учеников Хекслета. В качестве языка для демонстрации я использую JavaScript, как наиболее универсальный, но сами примеры никак не связаны с тем, какой язык используется. Эти ошибки встречаются везде в одинаковых пропорциях.
Вариант для самых мелких вместе с родителями. Игра без написания кода символами. Вместо этого надо задавать последовательность действий персонажа с помощью предложенных блоков.
2. Scratch
От 7 лет, в браузере и на десктоп
https://scratch.mit.edu/
Тут можно быстро лепить смешные анимации и игры. Все очень мультяшно и интерактивно. Изначально проект от MIT теперь набрал большую популярность и используется во многих школах и кружках программирования.
3. Codemonkey
от 7 лет, в браузере
https://www.playcodemonkey.com/
Тоже для ребенка и родителя, вместе. Если в Scratch нужно собирать простые алгоритмы из цветных блоков, то здесь уже надо печатать код чтобы помочь обезьянке получить обратно свои бананы. Удобно то, что все наглядно и интерактивно: напечатал код, проверил.
Не используйте чек-боксы в пользовательских интерфейсах. Используйте переключатели (radio buttons). У чек-боксов есть одно преимущество: они занимают меньше пространства. Но у них есть и серьезный недостаток: часто неясно, что значит неотмеченный чекбокс.
Вот несколько примеров. Первый — из формы настроек WillMaker от Quicken (сервиса для планирования наследственного фонда в США):
[ ] Отсортировать список контактов по фамилии
Quicken WillMaker отобразит контакты в списке, отсортированные по фамилии)
Понятно, что если чекбокс отмечен, список контактов будет отсортирован по фамилии. Но как он будет отсортирован, если чекбокс будет пустым? Очевидно, они обнаружили, что у пользователей возникли проблемы с этой позицией, потому что встроили в список справочный текст, но объяснение просто перефразировало предложение у чек-бокса. Лучше переделать, используя переключатели:
Код у программистов вызывает особую реакцию. Он может завораживать, восхищать или вдохновлять. А может разочаровывать, запутывать или даже вызывать страх. Недавно я спрашивал коллег, какие фрагменты кода произвели на них наибольшее впечатление. Из множества ответов я выбрал шесть, чтобы продемонстрировать разнообразие экосистемы, из которой складывается программирование. Каждый из примеров чем-то отличается, но все они одинаково впечатляют.
Строчки кода, которые для непосвященных могут выглядеть бредовыми, рассказывают истории об их авторах и пользователях: истории умных людей, людей практичных, творческих, сознательных или бесстрашных. В некоторых случаях от этих строчек кода зависели жизни людей.
Но почему мы так заботимся о том, чтобы код, который мы пишем, был элегантным и чистым? Компьютеру, безусловно, всё равно. Он добросовестно выполняет любые данные ему инструкции — без исключения, не задумываясь об их элегантности, эффективности, необходимости или разумности.
Я часто ловлю себя за чтением и изучением чего-то нового, потому что я любопытный человек. Я прочитал книгу «A Mind for Numbers» Барбары Оукли, чтобы улучшить и перевести на новый уровень процесс своего обучения. Этот пост – моя выдержка из книги. Тут содержится десять наиболее важных моментов, которые, как я думаю, те, кто изучает что-то новое, должны применять на практике.
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: большой системой огромных компьютеров, подключенных к радарным станциям и соединенных между собой. У них был графический дисплей с указательным устройством.
Реакция Джона была «Такая штука будет в каждом американском доме». Он понял, что сеть компьютеров — это по сути «информационная коммунальная услуга» (как вода, газ и т.д.)., и что домашние терминалы могут предоставлять разные виды «информационных услуг».
Привет, друзья. Недавно наткнулась на информацию о кривой забывания и подходам, необходимым для того, чтобы информация навсегда (или хотя бы подольше) оставалась в долгосрочной памяти. К обучению на Хекслете приступила недавно, и обучение здесь как раз и направлено на глубокое усвоение, но есть практики, которые необходимо добавлять в обучение самому.
Процент остаточных знаний во времени выглядит следующим образом. Тут следует учитывать, что имеется в виду умение воспроизвести и осознавать полученную информацию, а не ошибочное представление мозга о том, что "это всё я уже видел и знаю", хотя на деле связать воедино эту информацию не представляется возможным. Знать — не равно быть знакомым с материалом.
