Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

Когда я говорил вкладывать деньги в обучение специалистов, вы продолжали раздавать деньги за рекомендации. Теперь у нас никто не работает, а все рекомендуют.

Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).

Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.

Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?

Ответ на этот вопрос даёт мутационное тестирование.

Одна из главных проблем при написании крупных (относительно) программ на Python — минимизация потребления памяти. Однако управлять памятью здесь легко — если вас вообще это волнует. Память в Python выделяется прозрачно, управление объектами происходит с помощью системы счётчиков ссылок (reference count), и память высвобождается, когда счётчик падает до нуля. В теории всё прекрасно. А на практике вам нужно знать несколько вещей об управлении памятью в Python, чтобы ваши программы эффективно её использовали. Первая вещь, надо хорошо в ней разбираться: размеры основных объектов в Python. И вторая вещь: как устроено управление «под капотом» языка.

Начнём с размеров объектов. В Python есть много примитивных типов данных: целые числа (int), long (версия int с неограниченной точностью), числа с плавающей запятой (они же числа с двойной точностью, double), кортежи (tuple), строковые значения, списки, словари и классы.

Дмитрий Мелентьев, глава отдела проектирования компании Paneglif, специально для блога Нетологии рассказал о своем опыте тестирования прототипов при разработке программного продукта.

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



Рецепт есть: тестировать продукт перед выходом на рынок.

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

Диабет является одним из самых распространенных заболеваний во всем мире. В одной только России число диабетиков составляет 9,5 миллионов человек, в мире же это число достигает 422 миллиона, а это каждый 18-й человек.

Я, разработчик приложения для диабетиков, являюсь этим самым 18-м человеком, в 8 лет мне поставили диагноз «Диабет 1 типа».



Для тех, кто не очень знаком с этой темой объясню, что диабет – это аутоимунное неизлечимое заболевание, при котором организм человека сам не справляется с регулированием уровня глюкозы (сахара) в крови.

Из-за этого диабетикам первого типа приходится постоянно делать инъекции инсулина – в среднем 5 раз в день, и измерять уровень сахара в крови, прокалывая палец в среднем 7 раз в день. Диабетики второго типа чаще всего обходятся просто соблюдением диеты и приемом таблеток, но все равно иногда им приходится подключать и инсулинотерапию.

Как же мобильное приложение может помочь всем этим людям?

Как заметить, что для компании важно тестирование? Если компания спонсирует соответствующую конференцию, а её сотрудник выступает там с докладом — значит, важно. В случае с Grid Dynamics и конференцией Гейзенбаг всё обстоит именно так, и перед конференцией мы решили задать вопросы двум сотрудникам компании:

• Евгению Хорохорину, генеральному директору Grid Dynamics в России — о компании в целом
• Илье korobochka Коробицыну, ведущему QA инженеру, который и выступит на конференции — непосредственно о его работе

В очередной раз поводом для публикации послужило творчество музыкантов. На этот раз ими оказались шведы из инструментальной группы Wintergatan. Увидев, что соорудил бессменный лидер коллектива Мартин Мулин и его коллеги, я понял, что об этом стоит написать. Механический полуавтоматический акустический инструмент, названный Marble machine, поражает воображение. Скептиками высказываются мысли о том, что это вообще не может работать. Изобретательность автора, амбициозность проекта и смелость замысла граничат с лучшими проявлениями творческого сумасшествия.

Вот что строил испанский архитектор Антонио Гауди:



Его здания описывают как «бионические дома», некоторые говорят о «летящей пластичной материи». За морем восторгов художников и дизайнеров, как мне показалось, упущена некоторая невероятная рационализация и прагматичность. Гауди был в первую очередь отличным разработчиком, математиком и геометром. Но чтобы объяснить это, сначала я покажу другую картинку:


Это два крепления. Первое производится серийно — оно просто в проектировании, просто в изготовлении, дёшево и невероятно уродливо. Второе красивое, и требует на 25% меньше материала для того, чтобы выдержать тот же вес (то есть — куда прочнее). Только его трудно рассчитать, оно будет дороже в серии — и придётся подумать.

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

Как и обещал, рассказываю о том, как мы мигрировали свой бэкенд на Go и смогли уменьшить объем бизнес логики на клиенте более, чем на треть.

Для кого: небольшим компаниям, Go и мобильным разработчикам, а также всем, кто в тренде или просто интересуется данной тематикой.
О чем: причины перехода на Go, с какими сложностями столкнулись, а также инструкции и советы по улучшению архитектуры мобильного приложения и его бэкенда.
Уровень: junior и middle.

Модульность прочно обосновалась в мире javascript. Однако, при всех плюсах, писать в каждом файле одни и те же импорты — утомляет. А что, если убрать подключение часто используемых модулей в сборщик, а в коде использовать их как глобальные переменные? Выглядит, как задача для babel-плагина. Что же, давайте вместе напишем такой плагин, попутно разбираясь, как работает babel.

Тестирование программного кода — кропотливый и сложный процесс. Львиную долю работы в нем совершают unit-тесты. Пока они не «загорятся зеленым», тестировать дальше смысла нет.

Как же писать unit-тесты правильно? Стоит ли гнаться за 100% покрытием? С какими сложностями приходится сталкиваться инженерам на практике? Своим опытом делятся Marc Philipp и Всеволод Брекелов.

Хах! Кажется, что тимлид только и делает что таскает бумажки, пьет много кофе, шутит какие-то шутки, да и вообще он какой-то странный парень. Почему бы вам не занять его место? У вас большой опыт, вы знаете команду как свои пять пальцев, виртуозно владеете C++, С#, Java да и что там говорить — вы программист от бога!



Только вот руководство не замечает что «вы тут вообще за всю команду тащите» и проекты вытягиваете за неделю до дедлайна. Короче, вам пора руководить! Вы спите и видите как классно у вас всё выходит, производительность увеличивается, тендеры один за одним, всеобщее признание команды и начальства уже ваше всё. Вот только повышение осталось получить. А теперь к делу. Что же все таки мешает такому крутому спецу как вы вывести все из болота и управлять миром?

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

1. Обязательная часть тестирования – определение ожидаемого результата;
2. Программистам следует избегать тестирования их собственных программ (и участков кода);
3. Организациям, создающие программы, следует избегать тестирования их собственных программ;
4. Процесс тестирования должен включать в себя тщательную проверку результатов каждого теста;
5. Тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых;
6. Исследование Системы на предмет того, что она не делает того, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает;
7. Избегайте одноразовых тест-кейсов, только если сама программа не является одноразовой. Одноразовые тест-кейсы для одноразовых программ. В остальных случаях следует избегать таковых;
8. Не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок;
9. Вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок;
10. Тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие.

— Папа, а из чего состоят облака?
— Линукс сервера в основном...

Всем привет, давно что то не брал я в руки пера… По интересному стечению обстоятельств, я устроился работать в компанию которая сотрудничила с другой компанией, в области облачных технологий. На старой работе нужно было отработать 3 месяца и там еще новый год попался, словом, когда я пришёл уже к ним работать оказалось что: во первых, их продали и они теперь часть совсем не маленькой такой компании (названия умышлено не упоминаю дабы не сочли рекламой), а во вторых, облачная компания которая в девичестве звалась Cliqr (кто то может даже знает их по названию стартапа как osmosix) теперь же оказалась частью Cisco и сменила название на CloudCenter.

Поскольку я ничего не нашел тут про эту платформу, а по работе я только с ней теперь и работаю, я решил вам расказать вкратце что это такое, если будет интерес, смогу в следующий раз рассказать и как готовить :) Начну из далека…

С тех самых пор, как появились лицензии открытого кода, появился соблазн проверить их на прочность. GNU Public License самая бескомпромиссная среди них, она защищает свободу пользователя и программиста от присвоения результатов чужого труда, подмены открытого и общедоступного продукта, закрытым и платным. Не удивительно, что именно GPL чаще всего нарушают малые, средние и даже крупные компании.

Принуждение к соблюдению условий GPL является вопросом стратегической важности для открытого сообщества и легко понять почему это так. GPL является краеугольным камнем, точкой сбора сообщества и его самых принципиальных сторонников. Из них самый известный — основатель GNU и автор GPL — Ричард Столлман. Давайте узнаем как сообщество борется с нарушителями лицензии, кто нарушал и продолжает нарушать GPL и как экспроприируют экспроприаторов открытого кода.

В последнее время в крипто-среде стал популярен термин ICO – Initial Coin Offer. Этим термином обозначают процесс сбора инвестиций под тот или иной проект. Только вместо классических акций участникам за их инвестиционный вклад даются «коины» — некие электронные жетоны (записи в блокчейне), которые и подтверждают долю инвестора во владении проектом и соответственно – его долю в получении прибыли от проекта. Иными словами, под проект A выпускаются коины A, под проект Б – коины Б, и так далее. Коины, так же как и акции, имеют ценность только в рамках соответствующего проекта. Получается, что коины проекта А никак не влияют на коины проекта Б.

Артем Каличкин (ЦФТ)

Меня зовут Артем Каличкин, я работаю в компании «Центр Финансовых Технологий», которая занимает лидирующие позиции по производству и разработке программного обеспечения для банковского и финансового сектора. Я занимаю должность директора по сопровождению эксплуатации.

Возможно ли использование практик и подходов DevOps, CD в корпоративной среде? Какие особенности? SPARC + Unix (Solaris)? Вертикальное масштабирование и как следствие — разная конфигурация в бою и на стейдже. Об этом и поговорим.

Корректирующие (или помехоустойчивые) коды — это коды, которые могут обнаружить и, если повезёт, исправить ошибки, возникшие при передаче данных. Даже если вы ничего не слышали о них, то наверняка встречали аббревиатуру CRC в списке файлов в ZIP-архиве или даже надпись ECC на планке памяти. А кто-то, может быть, задумывался, как так получается, что если поцарапать DVD-диск, то данные всё равно считываются без ошибок. Конечно, если царапина не в сантиметр толщиной и не разрезала диск пополам.

Как нетрудно догадаться, ко всему этому причастны корректирующие коды. Собственно, ECC так и расшифровывается — «error-correcting code», то есть «код, исправляющий ошибки». А CRC — это один из алгоритмов, обнаруживающих ошибки в данных. Исправить он их не может, но часто это и не требуется.

Давайте же разберёмся, что это такое.

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

Внимание! Много текста и мало картинок. Я постарался всё объяснить, но без карандаша и бумаги текст может показаться немного запутанным.

На календаре май, а значит – «серая зона» праздников. Каждый, у кого выходил из строя сервис в праздники, знает, что такое две недели, в которых выходных больше, чем рабочих дней. По такому случаю рассказываем, как устроена наша техподдержка и что происходит с заявками, пришедшими в ночь с субботы на воскресенье. В конце статьи – небольшой чек-лист по составлению запроса в техподдержку. Чтобы на том конце провода вас правильно поняли и быстро смогли помочь.

— Что может быть хуже неэффективного совещания?
— Хуже может быть только неэффективное совещание длиной в три часа, где каждый из участников недоумевает: зачем он находится в этой комнате среди этих людей.



Статей и пособий на тему «Как провести совещание» написано великое множество. Казалось бы, тема исчерпала себя, поскольку есть четкое руководство: что такое «хорошо» и что такое «плохо». В таком случае, почему они не работают и компании по-прежнему тратят огромные суммы на «пустые» разговоры своих сотрудников?!

За десять лет регулярной организации совещаний в качестве менеджера проектов и фасилитатора (методом «проб и ошибок») у меня оформился список «подводных камней», которые могут привести к полному фиаско. Я не претендую на истину, поскольку все компании и команды разные. Многое зависит от корпоративной культуры и стадии развития компании, но есть моменты, которые будут актуальны для любой команды. Ниже я остановлюсь на самых важных:

— оправданность проведения совещания;
— время и длительность совещания.

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