Качество правописания у меня страдает. Решение – автоматическая проверка набираемых текстов прямо на уровне движка. Правописание можно проверять в комментариях и при наборе статьи. Для проверки используется API Яндекс спеллера.
Код и инструкция по установке – на гитхабе: https://github.com/podgorniy/blogengine-speller
Классы – круто. В es < 6 Так или иначе приходилось эмулировать создание классов, хоть и на прототипном наследовании. Поддержка на уровне языка дает чистый читабельный код.
Деструктивное присваивание, оператор spread и rest arguments используется не так часто, как мне казалось, когда я думал о es6.
Функции-стрелки – круто. Хоть я и писал серверный код, все равно пару раз понадобились, сделали код чище. Требуют сноровки и внимательности, чтобы не превратить код в нечитаемую лапшу, когда вкладываются одна в другую. Возможно я всего лишь еще не научился читать es6.
Квазилитералы волшебны. Для логгирования самое то. Опять-таки, из-за того, что приложение было серверным, строки со вставками вычислений не надо было генерировать в том количестве, что требует клиентский код.
Как только проект чуть разросся (5 классов), столкнулся с бедной поддержкой языка редактором (писал в саблайме). Переход к методу или классу не работает, а пользоваться поиском не с руки. Еще столкнулся с проблемой с подсветкой синтаксиса. Из-за непривычности синтаксиса допускал много ошибок, которые в редакторе не были видны, и приходилось запускать приложение, а потом из stack trace понимать в какой строке допустил описку.
Эти два фактора свели на “нет” все прелести нового стандарта, и в итоге недоделанный проект я переписываю на es5.на
Общие впечатления от es6 – самые теплые. Через пол года повторю эксперимент.
Писал код, прогоняя его через traceur-compiler. Для ноды разработка происходит прозрачно: скрипт инициализации проекта подтягивает traceur, тот умеет переписывать функцию импорта модулей, я указываю какие модули являются es6, и при их импорте traceur, прогоняет содержимое через свою магию. Все преобразования es6-es5 происходят в памяти, дополнительных файлов не создается. Проект стартует-рестартует быстро.
Если не понятно о чем я говорю, и интересно, то тут можно найти список статей, рассказывающих про новшества es6. А тут – посмотреть на слайды с моего выступления на оную же тему. (чтобы увидеть заметки к слайдам, перейди в режим перезентующего, нажав на клаве S)
UPD Поддержка Webstorm-ом es6 на порядок лучше того сетапа, которым я пользовался https://www.youtube.com/watch?v=jbfkcmxLLKY
Профессионалы развенчивают ложные модели непрофессионалов.
http://gutta-honey.livejournal.com/113296.html
Представление обывателя о том, что является нормой, а что патологией, и что все, что не норма, должно быть обязательно вылечено.
http://svictorych.livejournal.com/149809.html
Про ориентацию на цену при выборе товара. Ошибка заключается в том, что покупая самый дешевый товар, покупатель не выигрывает, а зачастую проигрывает (в качестве). Примечательно, что статистика берется из реальной сети розничной торговли.
http://svictorych.livejournal.com/76227.html
Про “плати человеку больше, и он будет работать лучше”. А вот и нет.
http://lurkmore.to/Культ_карго
Культ карго. Встречается и в более сложных формах (будем проводить собеседования как Гугл – будем такими же успешными, как гугл. Будем использовать ту же технологию, что и успешные компании на рынке – будем такими же успешными).
http://www.ellf.ru/cognitive/23406-karel-chapek-o-pravilakh-vedenija-diskussii.html
Некоторые приемы софистов, такие как caput canis (приписывание дурных качеств) – прямая эксплуатация кривых моделей мира. Разве может тот, кто изменяет жене с козой давать дельную критику работы государственного деятеля?
Модели могут работать без нашего понимания почему они работают, но при этом быть неверными. Например релятивистский закон сложения скоростей работает, до тех пор, пока складываемые скорости значительно меньше скорости света. Понять ложность релятивисткой модели обывателю невозможно.
Придумывая модель происходящего, и видя, что модель предсказывает будущее корректно, нельзя быть уверенным, что модель будет работать всегда. Что делать в таком случае? Придерживаться модели до тех пор, пока не найдутся ее опровержения или уточнения. Вносить правки, быть готовым пересмотреть убеждения, наслаждаться жизнью.
Выбор инструментов и технологий должен быть обусловлен критериями, в которых строится проект. Бюджет, размер команды, планы на будущее, опыт людей, с которыми нужно будет работать – все влияет на выбор инструментов. Молодые амбициозные технологии хороши для домашних проектов так как цены ошибки невелика, а шанс, что потенциал технологии будет соответствовать заверениям маркетологов, присутствует.
Проверенные временем, опенсорсные, на которые уже завязано много работающего кода – для потенциально долгоживущих за счет инертности. Бывает, лучше выбрать кривоватое решение с большим коммьюнити, чем прекрасное решение “в точку” без единой живой души, кто им пользуется.
Тем, кто убежден, что “популярность === высокое качество”, у меня плохие новости: ваше видение мира не соответствует действительности.
Для быстрого прототипирования нужны уже известные, ненакладные во времязатратах инструменты.
Пускать выбор технологий на самотек не стоит. Тогда в случае ошибочного выбора сложно будет извлечь опыт из ситуации (то есть сравнить предположения, ожидания с результатом)
Как ни крути, воспринимаемый нами мир, картинка в голове это не точная копия, а упрощенная модель. Упрощенная до такого состояния, которое необходимо для выживания. Держать в голове множества зависимостей, факторов накладно с точки зрения вычислительных возможностей мозга. Поэтому он стремится оптимизировать модель, конечно с некоторыми упущениями, которые не критичны для конечного результата – передачи своих генов. Так мозг работал миллионы лет. Он строил упрощенные модели. Видишь змею – беги, не раздумывай о том, что не все змеи ядовитые. Видишь животное – убивай, будет кусок мясной еды.
Из-за простоты мира наблюдения “если УСЛОВИЕ, то РЕЗУЛЬТАТ” можно предсказывать, зная только условие. Такие предсказания – ключ к выживанию наших далеких предков. Если солнце село, значит оно вскоре встанет. Если съесть этой травы, умрешь. Это золотой век (точнее миллион лет) абсолюта: все знания абсолютны.
Так привык работать наш мозг, и он был успешен. До совсем недавнего времени.
С развитием цивилизации изменились приоритеты жизненных задач, окружающий мир усложнился многократно (отношения, государства, рабочая иерархия, деньги, реклама; в этом списке все, что искусственно создано человеком).
Бояться змей – не стать серпентологом. Модель “змея = плохо” ломается. Змеиный яд, оказывается лечит. Не все растения вредны. Модель их понимания их выстраивают ботаники.
Знания наших предков зачастую упрощенные модели о мире, с допущениями, ошибками, и багажом предрассудков. Меня удивляют серьезные ученые, дающие отсылки к “народной мудрости”. “Утро вечера мудренее” работает, а лечение ран землей – нет.
Мошенники и иллюзионисты используют особенность нашего мозга строить наиболее вероятную модель происходящего. Оцените начало ролика https://www.youtube.com/watch?v=QcQxFkHGVvc
Информационный перекос, считай контроль государства над СМИ – способ заложить неверную модель представления о мире своему народу.
Неработающая модель мира может формироваться случайным образом, как следствие. Например идеал женского тела сформирован рекламой. И нравятся человеку толстушки. А вокруг культ костей. Куда ему податься? Отстаивать свою позицию, или довериться большинству? Когда все вокруг говорят, одно, ты думаешь иначе? http://youtu.be/MoeQ3I7BRpY?t=18m
Иногда модели самосбывающиеся. Например в банковской сфере. Люди считаю, что банк обанкротится, забирают свои сбережения, банк теряет оборотные средства и банкротится. Или например акции компании будут дорожать (или дешеветь) только потому, что люди так думают.
Иногда модели не соответствуют действительности. С приходом нового СЕО у компании растет прибыль. СЕО связывает успех со своим управленческим гением. Это его модель. А на самом деле весь рынок на подъеме, и любое решение привело бы компанию к текущим прибылям. Читай одураченные случайностью.
P.S. годная статья в тему: Почему возникают теории заговора и как с ними бороться
Есть 2 прекрасных инструмента, которыми я активно пользуюсь во время разработки. Это dash и alfred. Даш имеет плагин для интеграции с альфредом. Плагин работает криво, сначала предлагая список возможных вариантов выбора в выпадающем списке альфреда, в котором нужно тыкнуть интересующий вариант, и только потом откроется приложение даш. При этом плагин предлагает назначить отдельное сочетание клавиш на запуск даш, и на поиск выделенного текста в даш.
Какого поведения хотелось бы: по одному и тому же хоткею всегда открывается даш. Если был выделен текст, этот же текст ищется в даше. Реализация состоит из одной строки. Зная что даш регистрирует свой протокол, благодаря которому можно открывать окно поиска через консоль
open dash://forEach
, пишем скрипт открытия даша, куда аргументом передаем выделенный текст. Готовый воркфлоу: https://github.com/podgorniy/alfred-dash/blob/master/Dash.alfredworkflow?raw=true
После установки не забудь назначить хоткей для запуска воркфлоу. У меня это
ctrl+shift+d.
Под отладкой я принимаю необходимость подкрутить свойства стилей узла через вебинспектор, и сразу же увидеть результат применения. Осложняющим фактором будет видимое отсутствие элемента на странице. Элемент может быть не виден до определенного события. Может быть несколько причин невидимости. Рассмотрим случаи:
Случай 1. Тривиальный
Элемент находится в DOM, но скрыт, и появляется при наведении мышки на своего родителя.
В этом случае удобнее воспользоваться возможностью вебинспектора форсить состояние элемента будто на него наведена мышка. Обрати внимание, что элемент, на котором зафорсен hover, подсвечивается оранжевыми точками.
Страница для тренировки: http://dmitrypodgorniy.com/demos/dynamic-visibility/hover.html
В динамике:
Случай 2. Терпимый
Элемент добавляется и удаляется из DOM динамически. При этом DOM сам по себе не сильно изменяется. Такое поведение можно встретить на несложных сайтах с плагинами-меню. Чтобы отладить стили всплывающего элемента, словим момент добавления элемента в DOM с помощью установки breakpoint на мутацию DOM-а. Находясь в режиме отладки, хром не выполняет скрипты, которые должны бы скрыть элемент, но позволяет изменять стили элемента.
Не забудьте убрать breakpoint после того, как закончите отладку, чтобы не попадать в отладчик каждый раз при модификации DOM. Список всех breakpoint можно найти во вкладке “Sources”
Страница для тренировки: http://dmitrypodgorniy.com/demos/dynamic-visibility/dynamic-dom.html
В динамике:
Случай 3 (запущенный)
Элемент добавляется и удаляется с помощью js или с использованием хитрых стилей. При этом с первой попытки не удалось понять механику добавления, а DOM страницы меняется очень уж часто, и подход из предыдущего случая не помогает.
Идея – попасть в режим отладки прямо из консоли, введя debugger. При этом не потеряв фокус на странице. Помогает хитрость: нужно скрыть консоль, выполнить действие, чтобы элемент появился, открыть консоль (в этот момент она получает фокус, но фокус со страницы не пропадает), напечатать debugger. Теперь, в режиме отладки, можно менять стили, а элемент не будет скрываться, пока мы не выйдем из этого режима.
Страница для тренировки: http://dmitrypodgorniy.com/demos/dynamic-visibility/hover.html
В динамике:
