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



Автор статьи, перевод которой мы сегодня публикуем, говорит, что хочет поделиться советами, которые помогут Angular-разработчикам сэкономить немного времени. Он собирается рассказать о подводных камнях Angular, с которыми ему (и не только ему) довелось встретиться.

Как бы ни старались геймдизайнеры, в любой игре можно найти механику или контент, которые страдают от недостаточно детального продумывания. Последствия — от мелких эксплойтов до ненужных или даже вредных фичей.

В помощь геймдизайнерам придумана масса инструментов: форматы ГДД, различные чек-листы, юзерстори, портреты, агенда и так далее. И все равно этого не хватает.

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

Сейчас лето — то время года, когда во всём мире проводятся различные конференции и другие мероприятия. Программистов в эту пору буквально заваливает новой информацией, которую обычно бывает довольно непросто усвоить.

Вселенная фронтенд-разработки напоминает поезд, который движется без остановок. Все мы знаем о том, как сложно от этого поезда не отстать. Просмотр видеозаписей конференций занимает массу времени, в результате оказывается совершенно понятным причина того, что многие из нас, после офисной работы, предпочитают смотреть фильмы на Netflix.



Автор материала, перевод которого мы публикуем, говорит, что именно поэтому решил помочь всем желающим разобраться в новшествах Angular. Здесь пойдёт речь о современном состоянии Angular, о свежих возможностях этого фреймворка, об актуальных трендах.

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

Статья описывает поэтапный процесс написания шейдера травы в Unity. Шейдер получает входящий меш, и из каждой вершины меша генерирует при помощи геометрического шейдера травинку. Ради интереса и реализма травинки будут иметь рандомизированные размеры и поворот, а ещё на них будет влиять ветер. Чтобы управлять плотностью травы, мы используем тесселяцию для разделения входящего меша. Трава сможет и отбрасывать, и получать тени.

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

Реальная история, основанная на вымышленных событиях.
Все совпадения — неслучайны.
Все шутки — несмешны.

Если бы меня попросили дать один универсальный совет всем, кто ищет работу в IT, я бы сказал: не стесняйтесь задавать побольше вопросов. Мало приятного в том, чтобы через месяц осознать, что новая компания/должность — совсем не то, что вы искали. А если это вакансия с релокацией, цена ошибки возрастает в разы.

Узнав как можно больше о компании и должности, вы уменьшаете риск оказаться «в неправильном месте». Вместе с командой экспертов по поиску работы за рубежом из Relocate.me, мы собрали 20 вопросов, которые стоит задать, прежде чем пойти на работу в новую компанию.

Я живу на периферии технологической тусовки. И на периферии в географическом смысле. А это значит, что:

• Я никогда не был на профессиональных конференциях. Просто потому, что никогда не предоставлялось такой возможности.
• Я никогда не покупал обучающие курсы: для меня странно платить за то, что можно изучить самому в этих ваших интернетах или по книгам. Заманчиво, конечно, получить концентрированные знания, подкрепленные выполнением практических заданий, заполучить сертификат. Но на это у меня никогда не было ни средств, ни времени.
• Я адепт цифрового аскетизма: не по своей воле, но как порождение вечной перестройки в нашей стране. В короткие периоды финансовой стабильности я обновляю электронику по остаточному принципу. Вот и сейчас пишу этот текст на Core2Duo десятилетней давности. Все еще жду следующего стабильного плато на кривой моих доходов.
• Раза три в своей жизни я покупал игры. В 90-е. Это были кассеты для отживающего своё Спектрума. На покупку ПО я смотрю с удивлением: когда все пользовались пиратским ПО, то и я пользовался, не понимая сути вопроса. А потом, в начале двухтысячных, полностью перешел на Linux и покупать стало нечего.

Начинающие программисты тратят много времени, набирая знания, необходимые для прохождения интервью. Они решают задачи и улучшают свои резюме. Но самое интересное начинается после того, как программист получает вожделенную должность — в каком-нибудь стартапе, в Google, в Amazon или где-нибудь ещё. Нередко оказывается так, что те знания и навыки, которые помогли человеку найти работу, не соответствуют тому, что надо знать и уметь для выполнения его повседневных задач.



Автор статьи, перевод которой мы сегодня публикуем, говорит, что команда, в которой он трудится, воодушевилась рассказом TechLead’a о 7 привычках высокоэффективных программистов. Члены команды решили высказать собственные мысли по этому вопросу. Здесь, в форме советов, приведён разбор 7 навыков эффективных программистов.

Мы на «Моем круге» в последнее время прорабатываем профиль образования наших пользователей, так как считаем, что образование — как высшее, так и дополнительное — важнейшая составляющая современной карьеры в ИТ. 

Недавно мы добавили профили ВУЗов и учреждений доп. образования, на которых собирается статистика по их выпускникам, а также возможность указать в своём профессиональном профиле пройденные курсы. Затем провели исследование о роли образования в трудоустройстве и карьере ИТ-специалистов.

Далее нам стало любопытно, сколько зарабатывают выпускники разных ВУЗов, ставшие разработчиками и отработавшие после окончания образования 4 года или более. Сегодня попробуем ответить на этот вопрос.

Сканеры веб-приложений — довольно популярная сегодня категория софта. Есть платные сканеры, есть бесплатные. У каждого из них свой набор параметров и уязвимостей, возможных для обнаружения. Некоторые ограничиваются только теми, что публикуются в OWASP Top Ten (Open Web Application Security Project), некоторые идут в своем black-box тестировании гораздо дальше.



В этом посте мы собрали восемь популярных сканеров, рассмотрели их подробнее и попробовали в деле. В качестве тренировочных мишеней выбрали независимые точки на двух платформах (.NET и php): premium.pgabank.com и php.testsparker.com.

Я могу ошибаться, но предполагаю, что эти два совета помогут вам не наступать на те грабли, на которые я несколько лет подряд прыгал с разбегу. Особенно, если для большинства окружающих вы «разбираетесь в компьютерах» или, более того, ваша работа напрямую связана с помощью пользователям.

Совет первый: «не утверждай»

Все мои хорошие руководители учили меня тому, что никогда не следует что-либо утверждать, даже если ответ для вас очевиден (бумага белая, на улице жарко, сахар сладкий и т.п.). Изначально мне было тяжело это принять, особенно когда очевидный и полезный (по моему мнению) совет для человека приходилось заворачивать в такую «обёртку», что и самому-то было сложно понять изначальную идею.

Более-менее хорошо я начал усваивать этот урок только после того, как меня несколько раз очень здорово подставили коллеги и клиенты. Тогда мне повезло, все ситуации сошли мне с рук, но я получил очень неприятный осадок, правда вместе с осадком ко мне пришло понимание следующих вещей:

Почему у Фейсбука десятизначное число пользователей, а у большинства приложений — просто около десяти? Как побудить пользователей приходить снова и снова? Что движет ими?

Хотелось бы сказать, что я сейчас поделюсь с вами своей уникальной разработкой, но на самом деле она никакая не уникальная и ей не одна сотня лет.

Я предпочитаю название Фреймворк Папы Григория. Вам его составляющие наверняка знакомы как семь смертных грехов. Семь главных грехов. Peccata capitalia.

Давайте посмотрим как успешные приложения умело их используют и позволяют предаться всем им одновременно.

Папа Григорий в своем труде «Толкование на Книгу Иова, или Нравственные толкования» (Expositio in librum Iob sive Moralia) упорядочил их от самых простых в реализации, но привлекающих не всех, до самых сильных, над которыми, однако, надо потрудиться.

Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.

Закон Беттериджа гласит: «На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет». Те, кто знаком со мной лично, знают, что я не разделяю эту мысль. Но в этой статье я хочу пойти ещё дальше и доказать, что постановка вопроса из заголовка этой статьи просто не имеет смысла. Такая постановка вопроса предполагает, что существует компромисс между затратами и качеством. И необходимо постоянно соблюдать баланс. В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.

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

Есть такая фраза «Как бы хорошо вы ни воспитывали ребенка, ему все равно будет что сказать своему психоаналитику». То же самое можно сказать и про работу с сотрудниками. Как бы хорошо у вас ни было работать в компании, вашим сотрудникам будет что сказать о причинах ухода на собеседовании — это нормально. Но риски всегда можно минимизировать, а жизнь сотрудника в рамках компании — увеличить.

Мы решили проанализировать основные причины ухода разработчиков с предыдущих мест. Это не глубинные исследования, а кратковременный срез в моменте: просмотрели 175 заметок по итогам общения с разработчиками, которые процессятся на разных стадиях наших проектов, выбрали самые яркие высказывания и сгруппировали их по восьми темам.

По каждой теме есть рекомендации для представителей компаний и сотрудников, которые помогут двум сторонам или наладить сотрудничество, или расстаться с минимальными негативными последствиями.

Неналаженные рабочие процессы

Лидер нашей подборки. Встречается более чем в 60% причин при смене работы. Особенность в том, что это достаточно широкое понятие, которое включает в себя ошибки менеджмента, недостатки программного обеспечения, нехватку специалистов для реализации поставленных задач.

Привет, меня зовут Дмитрий, мне 35 лет. Раньше я часто слышал, что программист — профессия для молодых. Тем не менее прошлым летом я получил приглашение в Яндекс и перебрался работать в Москву.

В этой статье я хотел бы затронуть вопрос, который не раз обсуждался на Хабре: насколько реально быть программистом после 35–40 лет? Не ведущим архитектором, не тимлидом, не менеджером проекта, а именно программистом? Я не согласен с мнением, что программирование — это удел молодых. Считаю его вредным и сейчас расскажу почему.

Существует несколько доводов, на которые опирается этот миф. Давайте-ка их подробно рассмотрим.

Скоро наступит десятый год, как я профессионально занимаюсь программированием. Десять лет! И кроме формальной работы, почти две трети своей жизни я что-то создавала в интернете. С трудом вспоминаю годы, когда я не знала HTML: даже странно, если подумать об этом. Некоторые дети учатся музыке или балету, а я вместо этого создавала волшебные миры, кодируя в своей детской.

Размышляя об этом первом десятилетии регулярного получения денег за ввод странных символов в терминал, хотелось бы поделиться некоторыми наблюдениями, как изменилось моё мышление за годы работы.

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



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

Что бы ни сказали — не станем спорить
Что бы ни дарили — не станем верить
Егор Летов «Как листовка»

Думаю не стоит лишний раз говорить о нашумевшем сериале Чернобыль и эффективности такого «сериального» воздействия на массы. Особенно на массы, проживающие на территориях, показанных в фильме. Выход каждой новой серии сопровождается всплеском публикаций в FB. В каждой из которых горечь, страх, боль. Что в такой ситуации я могу сделать ("кто виноват и что делать?")? Могу только описать свой взгляд на терапию лучевых поражений. Спасибо родненькой кафедре химии высоких энергий и проф. Шадыро О.И., которые пестовали в своих лабораториях нас, непутевых фармацевтов-радиохимиков. Надеюсь своей статьей честь этой, легендарной некогда, кафедры я не опорочу.

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

В общем, спасибо, сценаристы HBO, за то, что всколыхнули Память. Мой посильный вклад — под катом. Рейтинг доступных (и не очень) антидотов, способных сработать при радиационном выбросе. В закладки — класть строго ВСЕМ! И прочитал сам — перекинь другу.

Сегодня мы поговорим немного о настоящем, будущем и о программе конференции DevOops 2019.  DevOps меняется с каждым днём. Вы помните 2004 год? У нас есть спикер, который работал с облаками в то время, когда и термина такого не было. Amazon Web Services запустили в 2006 году. Где-то в то же время начали появляться первые упоминания «DevOps». С тех пор прошла целая жизнь.

Недавно снова вспоминали «верните мой 2007». Представьте себе этот мир без вездесущих виртуалок на Amazon, без GitHub (он появился только в 2008), без уютных и безопасных докеров. Вспомните настройку iptables, пакетные менеджеры GNU/Linux, ручную пересборку модулей ядра, бессонные ночи. Всё ещё хотите туда? Вот такой был бы ваш 2019, если бы не ураганный прогресс этих лет.



Менялись технологии и компании. Приведу пару примеров. Например, все мы увидели чудесное преображение Microsoft – от Баллмеровского «Linux is Cancer» в 2001 году до повсеместного перехода на open source, спасения GitHub в 2018 и планов летом 2019 года представить ядро Linux как часть поставки Windows. Вместе со всей этой движухой менялись и предпочтения инженеров относительно получаемой информации.

Ведущий разработчик — не зря «ведущий». Эту фраза была услышана на одной из конференций по IT-менеджменту и вызвала вопрос, а почему собственно «не зря»? Именно этот вопрос и подтолкнул меня написать эту статью.



Оценивая свой опыт, могу сказать, что основные характеристики ведущего разработчика можно свести к 3 пунктам:

• Думает не только о своей грядке, но и обо всем огороде (это ключевое качество). Готов выстраивать стандарты и следить за их исполнением.
• Отлично знает свой язык и фреймворк, превосходно разбирается в архитектуре, имеет солидный опыт работы за плечами. «Солидность» не обязательно означает время проведенное за клавиатурой, важно количество и качество написанных проектов.
• Хочет и может аргументированно доносить свое мнение, отстаивать его и искать компромисс при необходимости.

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

Одной из сильнейших его сторон является целостная картина мира, в которой совершенно точно определено, что такое хорошо и что такое плохо. Это позволяет быстро принимать решения и без колебаний воплощать их в жизнь. Эта уверенность заразительна и позволяет завоевать авторитет в глазах менеджеров, у которых уже не все так просто и понятно. Ведь кроме технических «лучше», «надежнее» и «быстрее», на уровне менеджмента появляются всякие «заказчик не захочет», «инвестор не оценит» и всевозможные «Вася обидится». Когда менеджер слышит «нет, тут нужно делать только так, потому что 1, 2 и 3» — он вздыхает с облегчением. Выбор становится очевиден и ответственность падает с его плеч.

Чуть более года назад я ушел с позиции ведущего разработчика окончательно и решил сделать небольшую ретроспективу своих самых досадных ошибок. Итак:

Ошибка номер 1. Оверменеджмент