Итоги развития Байнета и отечественной доменной зоны от белорусского телевидения, советы по борьбе с выгоранием на работе и Regex-кроссворды, а также свежие ссылки по JavaScript и C, национальные особенности PM и специфика выбора методологий разработки — в первом недельном ссылкообзоре 2016 года.
Итоги развития Байнета и отечественной доменной зоны от белорусского телевидения, советы по борьбе с выгоранием на работе и Regex-кроссворды, а также свежие ссылки по JavaScript и C, национальные особенности PM и специфика выбора методологий разработки — в первом недельном ссылкообзоре 2016 года.
Довольно необычный ракурс обзора — мнения о трендах Байнета с точки зрения белорусского телевидения. Прямая ссылка на видеозапись программы вот тут.
2015 год войдет в историю белорусского Интернета. О развитии байнета и доменов.БЕЛ, популярных сайтах у белорусов и новых сервисах в Интернете — сегодня в «Актуальном интервью».
О развитии байнета и доменов бел — сегодня в «Актуальном интервью» https://t.co/lQaabXVcep
— Белтелерадиокомпания (@www_tvr_by) December 30, 2015
Из интервью для примера озвучу лишь один факт: доменная зона.by сейчас демонстрирует самые быстрые темпы роста в Европе. Осталось только добавить, что интервью даёт Сергей Повалишев, директор hoster.by (технический администратор доменов.BY и.БЕЛ).
Десять мнений: как быть айтишнику при «выгорании»:
Полагаю, всем, кто работает в сфере информационных технологий (кодерам, админам, безопасникам, тестировщикам…), знакомо состояние серости и безысходности, когда работа начинает казаться нудной, решаемые задачи — неинтересными, когда хочется бросить всё и начать новую карьеру — скажем, альпиниста или пастуха овец. Одни называют это состояние «творческим кризисом», другие — «выгоранием», третьи — «хандрой». У кого-то оно длится неделю, а у кого-то растягивается на месяцы. Но, думается, все согласятся, что состояние это очень неприятное и рано или поздно с ним сталкивается каждый. Вот о том, почему возникает выгорание, как его предотвратить, и как правильно выходить из такого состояния, мы и поговорим в этой заметке.
В качестве пассивного отдыха хочу предложить любимое развлечение старшего поколения: RegEx-кроссворды. Это обычные кроссворды, созданные на основе регулярных выражений. Это хороший сервис для ненапряжной проверки знаний и чисто программистского досуга.
Не только переработка тревожит айтишников в наше время. Далее ссылка на большой материал-интервью о том, как Элон Маск и Y Combinator не позволят искусственному интеллекту захватить мир. В частности они финансируют новую организацию OpenAI, чтобы разработать самую совершенную форму искусственного интеллекта и подарить её людям.
Напугала их, судя по всему, вот эта революция искусственного интеллекта от 2015 года.
Помните, как недавно компьютер прошел тест Тьюринга? Давайте уже разберёмся с тем, что такое сверхинтеллект, чего нам от него ждать и куда вообще ведут нас все эти компьютерные технологии.
Цитата из комментариев:
Отличная статья, но несколько моментов:
- Не согласен с выводом автора о том, что сверхинтеллект не может поменять свои цели только на том основании, что это похоже на антропоморфизацию. При прыжке от AGI до ASI может оказаться сколько угодно новых сверхинтеллектов и векторов их развития, не заложенных в основном AGI. Три закона Азимова не окончательное решение (кстати, удивлен, что автор их не упомянул), и их уточнение и развитие всё ещё продолжается. На это работает целое направление философии.
- Не рассмотрено узкое место производства при технологической сингулярности. Так или иначе, для физических экспериментов понадобятся массивные проекты среди которых Большой Андронный Коллайдер (строительство которого продолжалось 8 лет и потребовало огромных человеческих и других ресурсов) покажутся детской песочницей. Можно утверждать, что все эксперименты легко просчитываются на компьютере (как сейчас делают в военной атомной сфере), но подтверждение и физическое вопрощение потребует гигантских ресурсоёмких проектов.
- Не до конца рассмотрен симбиоз органики с технологиями. Сверхинтеллект может решить что органическая модель развития и клонирования в виде ДНК (или подобного) — эффективный метод распространения алгоритмов и методов их решения. Может даже и не органическая, основанная на безкислородной среде, но с таким же процессом клонирования. В результате получим корабли летящие в разные стороны галактики, несущие модели ДНК заточенные под точку назначения. Используя рекурсию, приходим к выводу что искать доказательство внеземного ASI (на возможное отсутствие которого указал автор) можно в нашем же ДНК.
Это интересная и отчасти мистическая история, богатая полезными практическими выводами: Как я искал (и нашёл) разницу в двух побайтово идентичных файлах.
А начиналось всё довольно-таки банально…
Наши плагины представляли собой обычные.NET-сборки, которые нужно было подкинуть в определённую папку, откуда основное приложения их загружало и использовало. Ну, вы, наверное представляете как — Assembly.Load (), дальше ищем класс, реализующий необходимый интерфейс, создаём объект этого класса и т. д. Всё это работало давно, стабильно и ничто не предвещало беды. Но вдруг в какой-то момент появилась необходимость создать плагин, состоящий из нескольких файлов.
В связи с этим было решено считать плагином не просто.NET-сборку (1 файл), а zip-архив, в котором может быть как одна сборка, так и несколько файлов. В связи с этим пришлось научить билд-сервер паковать плагины в архивы, а основное приложение — разархивировать их в нужное место. В общем-то задача на 10 строк кода. Ничто не предвещало беды. И вот скачиваю я с билд-сервера собранный архив с плагином, разархивирую его в нужную папку, запускаю приложение, и… не работает! Стоп, как не работает? Это ведь тот же плагин!
Под впечатлением от этого материала другой человек написал душеполезное продолжение по теме: Почему я перепроверяю записанные данные, или История одного расследования.
Печальные итоги давней истории про то, как один «хороший» программист решил бесплатно научить программированию бездомного доходягу, дабы тот выбился в люди. Уроки неудач: Лео Гранд и судьба программера-одиночки.
Если вас интересует морально-эволюционная подложка этой истории по Дарвину с расширением контекста, советую читать давний материал Голубицкого: Чудо Карнеги продолжается: Follow-up-истории Патрика и Лео. Закончу комментом, взятым отсюда:
Как-то в Таиланде общался с буддистскими монахами (настоящими, а не с теми, которые по три месяца сидят в монастыре). Так вот, их часто спрашивают: «Монастыри обычно богатые — им жертвуют богатые люди, и когда ты медитируешь, то один раз в день поесть — вполне достаточно, а такая еда в Таиланде есть круглый год и ничего не стоит. Чего вы ходите и пожертвования у простых людей просите?».
Ответ обычно разрывает шаблон, потому что они говорят: «Нам эта милостыня, в принципе, не нужна. Монахам много не нужно, и монастырь действительно может его снабдить всем необходимым. Но они ходят и просят, чтобы дать возможность обычным людям совершить добрый поступок».
Другими словами, это не им нужна твоя подачка, это тебе нужно подавать, чтобы использовать довольно редкую в этой жизни возможность сделать что-нибудь хорошее.
Идея, что все должны горбатиться ради «великой-любой-страны-мечты», тратить свою жизнь на зарабатывание денег на новый айфон, сама по себе несет в себе зачатки тоталитаризма. Сидеть в переходе — та ещё работка, полагаю, что гораздо тяжелее, чем за компьютером штаны протирать.
Попытка подвести некие итоги года: Обзор возможностей современного JavaScript. Много примеров, различные стили и подходы кодирования, ECMAScript 2015.
Исходя из рекомендаций материала, читатели сразу пишут первый коммент:
let sayHappyNewYear = year =>
`Happy New ${year} Year!`;
sayHappyNewYear(2016);
На что этот новогодний коммент разбирают на части критики:
На самом деле, это не очень хороший пример, который хотелось бы демонстрировать новичкам JS. Нативные шаблоны — это гуд. А вот укороченные стрелочные функции надо использовать осторожно, по крайней мере, в обычных незамысловатых ситуациях. У них есть несколько ограничений:
- Во-первых, стрелочная функция запускается всегда с контекстом того места, где она описана. То есть,.apply () и.call () использовать с такими функциями бесполезно.
- Во-вторых, стрелочные функции не создают объекта arguments, который можно было бы использовать в теле стрелочной функции.
- В-третьих, несмотря на явное название функции sayHappyNewYear, она всегда остается анонимной.
- В-четвертых, (не самое главное) определив функцию обычным образом function sayHappyNewYear (year) {… }, например, в глобальном окружении, функцию можно использовать где угодно, хоть после определения, хоть до определения. Переменные, определенные через let, доступны для использования лишь после определения.
Ещё комментарий по поводу текста:
Статья несёт несколько провокационный и популистский характер. И при этом практически никакой информации о ES6 и его возможностях (кроме того о чем пишут уже пол года все кому не лень). Только очередной повод разогреть холивар «неправильный ООП» vs «функциональная чистота».
Задача, описанная вами, решается не наследованием, а композицией объектов, классов в JS как не было, так и нет. Это как назвать классотипы в хаскеле классами, сравнивая оные с Java-скими.
Более того, это ребятам с Java/C# приходится плодить на такие вещи классы, банально потому что в этих языках нет отдельной сущности «функция». Ребята, пишущие на Python, например, за такие наговоры обиделись бы. Вообще Python сообщество имеет всё то же, что в JS (модули, «классы» и т. д.) уже довольно давно. И стоит иногда присматриваться к тому, как они комбинируют ОО подходы и функциональщину.
Да и мне кажется, что вы как-то странно реализовали «композицию» функций, больше на каррирование похоже. Опять люди концентрируют внимания на различиях в подходах, вместо того что бы брать лучшее из того и другого.
Вдогонку: 10 Most Recommended JavaScript Scene Articles of 2015.
Я постараюсь максимально доходчиво рассказать со стороны атакующего о Format String Attacks, однако с некоторыми упрощениями. На практике они достаточно просто разрешаются, но не очень хочется на них зацикливаться. Кроме того, самых стойких, долиставших до конца, помимо бесценных знаний ждет небольшой бонус.
Как вы уже могли заметить, printf ()-like функции обладают колосальной мощью. Более того абсолютной, ибо как оказалось они и еще тьюринг-полные, а значит потенциально могут содержать вс, что будет угодно хакеру.
Ещё один хороший материал о таинственной мощи функции printf.
Из последнего процитирую лишь вывод:
Здесь рассмотрено только два простых примера уязвимости. Конечно, их существует намного больше. Здесь не делается попытка описать или хотя бы перечислить их. В статье планировалось показать, что опасность может представлять даже такая простая конструкция как printf (name).
Отсюда следует важный вывод. Если вы не специалист по безопасности, то лучше следовать всем рекомендациям, о которых пишут. Суть рекомендаций бывает слишком тонка, чтобы оценить весь спектр угроз самостоятельно. Ведь вы наверняка читали, что printf () опасная функция. Но я уверен, что многие, из читающих эту статью, впервые узнали о глубине кроличьей норы.
Кто-то, прочитав вывод, сказал — «это и так было понятно». Но будьте честны. До прочтения этой статьи вы знали и помнили о том, что printf () может писать в память? А ведь это является большой уязвимостью. По крайней мере, являлось таковой раньше. Сейчас есть другие, не менее коварные.
Свежее мнение Сергея Теплякова об известной книге Роберта Мартина «Профессиональный программист». Вот подборка хронологии взглядов Сергея:
У меня со стариной Бобом складываются довольно сложные односторонние отношения. Когда-то, он был моим чуть ли не кумиром, но после внимательного прочтения его книги «Принципы, паттерны и методики гибкой разработки» мое мнение сильно изменилось. Теперь же любой его труд мне читать стало заметно сложнее, поскольку явно начал проявляться «баг» под названием «подтверждение предвзятости». Я стал находить все больше и больше непонятных мне моментов и все меньше полезных советов. Но поскольку большинство книг «дядюшки» Боба весьма известны и обладают высоким рейтингом, я не могу пройти мимо и не поделиться с вами своим впечатлением от прочтения очередного его творения.
В развитие темы: блок-схема выбора оптимальной методологии разработки ПО:
Два емких и критических комментария к статье:
Методологию, как и Родину, не выбирают.
В любой компании уже есть сложившиеся процессы. Эти процессы формируются годами. Создаётся организационная структура, допиливаются рабочие инструменты. Если вы пришли работать в компанию, вы не можете просто взять и выбрать методологию. Выбора между Waterfall и XP в пределах одной компании просто не существует.
Если в компании используется RUP, значит, она сидит на инструментах Rational, на которых вообще всё является RUP’ом.
RAD сегодня существует только в книгах.
И даже если вы включили God mode (сами создаёте компанию и формируете с нуля команду для собственного нового продукта), вы не сможете просто так взять и выбрать методологию.
Второй читатель вторит:
Не суть метода определяет выбор, а требования по эффективности определяют выбор метода. Критерии на диаграмме берутся из различий методов, в то время как реально используемый метод — чаще всего сочетание элементов практик (с преобладанием чего-то конечно).
Я уже писал тут эти мысли, но повторюсь. Метод не делает проект успешным, перечисленные методы — про организацию процесса разработки. Управление проектами лежит за рамками этих методов, и оно и отвечает за выбор производственного решения.
Теперь ближе к делу. Достаточным критерием эффективности является эффективность экономическая. Её можно измерять как соотношение прибыли к риску, и если исходить из этой метрики, мы должны выбирать тот метод, который это соотношение максимизирует.
- Низкий риск и низкая прибыль (например, это заказные проекты, услуга по сути) — нужен самый экономичный процесс, и я склонен полагать что это что-то околоводопадное — как минимум потому, что каждая задача делается один-два раза.
- Низкий риск и высокая прибыль (случай монополии) — нужен метод, который позволит эту самую монополию не растерять. То есть быстро и качественно, и это (не поверите), канбан. Канбан обеспечивает качество возвратом задач.
- Высокий риск и высокая прибыль (конкурентный рынок, инициативные проекты и стартапы) — подходит гибкий метод, который постоянно выдает максимум результатов. Скрум короче.
- Высокий риск и низкая прибыль (начало работы с гос. организациями или другими крупными компаниями на конкурентном рынке) — тут лучше вообще перейти в другую нишу — поставок «комплектующих» для тех, кто работает на этом рынке. Если всё же работать на таком рынке, то нужен свой продукт, разрабатывать который можно спирально или по RUP (помесь водопада и гибких методов, водопадненькие итерации).
Проблема аджайла (хотя я к нему отношусь ровно, спокойно, с пониманием) на самом деле в том, что он плохо разграничивает управление продуктом и проектом. Вот бэклог — это про список тасков или про список требований? Неоднозначно, хотя тут можно городить огороды, прав никто не будет (даже я:)). В сухом остатке имеем, что когда продукт отчуждается — нет смысла использовать полностью гибкие методы, так как затраты на организацию и поддержание этих методов сожрут немалую часть времени, в то время как профитов с этого нет. Когда проект инициативный (собственный) — гибкие методы позволяют решать достигать более точных результатов.
С точки зрения системного подхода, гибкие методы дают более быструю и тонкую подстройку продукта под окружение проекта, в то время как более длинные заранее спланированные разнозадачные водопадные итерации дают возможность оптимизировать/экономить.
*Мнение колумнистов может не совпадать с позицией редакции.
**В цитировании сохранены авторская орфография и пунктуация.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.