При всей моей нелюбви к творчеству Ли Хаойи, это решение не самое худшее (scalatags) — типобезопасное и может достаточно просто быть расширено. Конечно, читать не слишком просто, но возможность мне, как бэкендщику, перестать дебажить HTML стоит немало. Опять же, JSX/HTML транслируется в эту муть достаточно просто.
я на данный момент занимаюсь разработкой в неком стартапе, у которого, кроме бизнес-пользователей, есть еще две категории разработчиков:
— математики/актуарии, которые привыкли к питону 2.
— современные разрабочики, интегрирующие нашу систему в целевые платформы, разрабатывающиеся сейчас, язык интеграции — питон 3
Первых с каждым годом становится все меньше, вторых все больше (с учетом того, что многие компании пинками загоняют своих разработчиков только в питон3).
Ну так вот. Я это научное сообщество, которое привыкло к двойке и не привыкло меняться, хочу молотками по головам постучать. Они любят, например, jupyter, у которого ядро по умолчанию — питон 3. И любят они numpy/scipy etc, которые тоже сейчас по умолчанию под питон 3 разрабатываются. Но — они будут плакать и колоться, но жрать кактус, пытаясь установить jupyter + scipy + matplotlib + еще кучу всего, вместо двух команд в pip3.
«Большая нагрузка» — как «большие данные». С одной стороны баззворд, с другой — для каждого свое понимание. Наверное, как и в случае с большими данными, это когда не помещаешься в один сервер уже по физическим ограничениям (например, совокупный объем передаваемых данных больше гигабитного сетевого канала)
Коллега, работавшая в гугле, написала маленький сервис, который обрабатывал 200 тысяч запросов в секунду на нескольких серверах, и не считала это большой нагрузкой.
Дружище, разработка — это просто, когда у тебя есть:
— лет хотя бы 10 опыта разработки, причем и для себя, и для кого-то (за деньги)
— хотя бы пара разных компаний, лучше 5, чтоб взгляд был разнообразный
— опыт наступания на грабли всех возможных конфигураций
— IQ больше возраста твоей бабушки
— самое главное — любознательность.
И вот тогда ты готов стать junior разработчиком, а не кнопконажимателем.
Глен Майерс написал свою книгу в 1978 году. Со временем, эта книга не потеряла своей актуальности, а даже наоборот.
Только вот ведь какая незадача — большинство этих самых свитчеров, прочитав ее, не смогут не то, чтобы начать использовать в реальной работе, а даже банально понять.
В смысле? У меня есть 4 файла:
— build.sbt — описание всех проектов и подпроектов. Чаще всего делается с нуля для каждого.
— project/Dependencies.scala — я так привык задавать разные зависимости и делать package sets
— project/plugins.sbt — подключение плагинов. Мигрирует из проекта в проект
— settings.sbt — настройки scalariform, revolver, packaging, web plugin etc
Иногда еще таски дополнительные делаю, но там зависит.
Где там мусор? Когда в проекте 300 файлов исходников, 4 файла которые управляют всем билдом, все аккуратно разнесено по нужным файликам, каждый из которых не более 20 строк.
Если писать не hello-world, то билд-система должна быть достаточно мощной, но и простой для начинающих. В sbt, соглашусь, классовый переход между простотой и мощностью чуток затянут, не спорю, но для понимания достаточно один раз посмотреть видео выше.
Чтобы с sbt разобраться нужно посмотреть выступление Даниэля Вестхайда с ScalaDays 2013? 2014? — он очень классно за час все объясняет. www.parleys.com/talk/learn-you-sbt-fun-profit
После этого мои волосы стали мягкими и шелковистыми, а билды — простыми и надежными
В этих статьях-переводах отсутствует важная часть из первых пары глав — если есть глава на плечах, и отлично понимаешь, что делаешь, это не антипаттерн.
Именно про это! Но (как обычно, «но»)… как раз про современные реалии.
Как параллелизировать задачу и разнести по ядрам и компьютерам? Самый простой способ — разбить на те самые идемпотентные функции, работающие с immutable структурами данных, в отличие от тех самых толстых объектов.
С учетом того, что «работает на одном компьютере» или «работает на одном ядре» — современные аналоги «работает на моем компьютере» или «640 Кб памяти хватит всем», подобная обработка данных становится мейнстримом, а не исключением. Причем даже не только сейчас, а уже давненько, например, когда появились import static в джаве — уже тогда стало понятно, что не все должно быть в классе или объекте.
Я изначально то и имел в виду под тем, что это не антипаттерн — за последние 17 лет, прошедших с выхода оригинальной книги, многое в мире поменялось. Сейчас как раз ее перечитываю на перекурах, и думаю, что если ее воспринимать через призму реальности и опыта — книга не потеряла своей актуальности, но если ей следовать дословно (боже, вспоминаю CORBA и IDL, и дрожь берет) — она будет поопасней, чем «майн кампф» для неокрепших умов.
В современных реалиях, на мой взгляд, одним из самых главных антипаттернов является называние функциональной декомпозиции антипаттерном.
Не всегда и не везде нужно применять ООП. Нередко задача решается проще и тестируется лучше, если она написана как набор идемпотентных функций над структурой данных, чем если она инкапсулирована в стандартные толстые объекты, смешивающие логику и состояние.
Один из вариантов — идти на EAP у издательств, и смотреть книги, которые в процессе написания.
Например, я люблю скалу и кложу, у меня на данный момент 9 книг в MEAP от Manning — и про reactive programming, и новые издания уже имеющихся книг — и с каждым апдейтом (новой главой) я могу выделить вечер-другой, чтоб прочитать и попробовать, что там написано.
С другой стороны, есть книги, которые в принципе нужно читать не сильно связанные с программированием, например, тот же Concrete Math Грэма/Кнута/Паташника. Опять же — сесть и прочитать полностью — слишком долго, читать по главе и делать упражнения очень помогает в качестве зарядки для мозга.
Почему же? Просто порог вхождения чуть-чуть выше, чем у джавы, но и продуктивность тоже. По сравнению с ПэХаПэ и джаваскриптом и на джаве никто не пишет…
— математики/актуарии, которые привыкли к питону 2.
— современные разрабочики, интегрирующие нашу систему в целевые платформы, разрабатывающиеся сейчас, язык интеграции — питон 3
Первых с каждым годом становится все меньше, вторых все больше (с учетом того, что многие компании пинками загоняют своих разработчиков только в питон3).
Ну так вот. Я это научное сообщество, которое привыкло к двойке и не привыкло меняться, хочу молотками по головам постучать. Они любят, например, jupyter, у которого ядро по умолчанию — питон 3. И любят они numpy/scipy etc, которые тоже сейчас по умолчанию под питон 3 разрабатываются. Но — они будут плакать и колоться, но жрать кактус, пытаясь установить jupyter + scipy + matplotlib + еще кучу всего, вместо двух команд в pip3.
Коллега, работавшая в гугле, написала маленький сервис, который обрабатывал 200 тысяч запросов в секунду на нескольких серверах, и не считала это большой нагрузкой.
— лет хотя бы 10 опыта разработки, причем и для себя, и для кого-то (за деньги)
— хотя бы пара разных компаний, лучше 5, чтоб взгляд был разнообразный
— опыт наступания на грабли всех возможных конфигураций
— IQ больше возраста твоей бабушки
— самое главное — любознательность.
И вот тогда ты готов стать junior разработчиком, а не кнопконажимателем.
— Don't tell me what to do!!!
Только вот ведь какая незадача — большинство этих самых свитчеров, прочитав ее, не смогут не то, чтобы начать использовать в реальной работе, а даже банально понять.
— build.sbt — описание всех проектов и подпроектов. Чаще всего делается с нуля для каждого.
— project/Dependencies.scala — я так привык задавать разные зависимости и делать package sets
— project/plugins.sbt — подключение плагинов. Мигрирует из проекта в проект
— settings.sbt — настройки scalariform, revolver, packaging, web plugin etc
Иногда еще таски дополнительные делаю, но там зависит.
Где там мусор? Когда в проекте 300 файлов исходников, 4 файла которые управляют всем билдом, все аккуратно разнесено по нужным файликам, каждый из которых не более 20 строк.
Если писать не hello-world, то билд-система должна быть достаточно мощной, но и простой для начинающих. В sbt, соглашусь, классовый переход между простотой и мощностью чуток затянут, не спорю, но для понимания достаточно один раз посмотреть видео выше.
www.parleys.com/talk/learn-you-sbt-fun-profit
После этого мои волосы стали мягкими и шелковистыми, а билды — простыми и надежными
Как параллелизировать задачу и разнести по ядрам и компьютерам? Самый простой способ — разбить на те самые идемпотентные функции, работающие с immutable структурами данных, в отличие от тех самых толстых объектов.
С учетом того, что «работает на одном компьютере» или «работает на одном ядре» — современные аналоги «работает на моем компьютере» или «640 Кб памяти хватит всем», подобная обработка данных становится мейнстримом, а не исключением. Причем даже не только сейчас, а уже давненько, например, когда появились import static в джаве — уже тогда стало понятно, что не все должно быть в классе или объекте.
Я изначально то и имел в виду под тем, что это не антипаттерн — за последние 17 лет, прошедших с выхода оригинальной книги, многое в мире поменялось. Сейчас как раз ее перечитываю на перекурах, и думаю, что если ее воспринимать через призму реальности и опыта — книга не потеряла своей актуальности, но если ей следовать дословно (боже, вспоминаю CORBA и IDL, и дрожь берет) — она будет поопасней, чем «майн кампф» для неокрепших умов.
Не всегда и не везде нужно применять ООП. Нередко задача решается проще и тестируется лучше, если она написана как набор идемпотентных функций над структурой данных, чем если она инкапсулирована в стандартные толстые объекты, смешивающие логику и состояние.
Например, я люблю скалу и кложу, у меня на данный момент 9 книг в MEAP от Manning — и про reactive programming, и новые издания уже имеющихся книг — и с каждым апдейтом (новой главой) я могу выделить вечер-другой, чтоб прочитать и попробовать, что там написано.
С другой стороны, есть книги, которые в принципе нужно читать не сильно связанные с программированием, например, тот же Concrete Math Грэма/Кнута/Паташника. Опять же — сесть и прочитать полностью — слишком долго, читать по главе и делать упражнения очень помогает в качестве зарядки для мозга.