Всем бойцам РХБЗ (радиационной, химической и биологической защиты) не посрамившим честь своего ОЗК посвящается...

С интересом читая статьи коллеги gjf про самые интересные, самые страшные и самые нестрашные яды испытываю ностальгию :). Потому что любой правильный химик, начиная свой творческий путь в первую очередь интересуется либо ядами, либо взрывчатыми веществами, либо наркотиками. Вот не встречал людей, которых в химию бы привело что-то другое, честно. Правда с годами, если хобби становится профессией, вся информация как-то переосмысливается и упорядочивается, возникают совершенно иные приоритеты. Вот и теперь, читая упомянутые статьи я вспоминал свой бумажный блокнотик, в котором в том числе были и описания необычных ядов. Все течет, все изменяется, теперь в моем «рабочем» блокноте чаще встречаются «противоядия». Ибо человеком придуманы тысячи способов уничтожить жизнь и пока не придумано ни одного — ее создать. Сила — в равновесии, поэтому если на Хабре есть яды — должны быть и противоядия. Ну и проснулся ж во мне перманентно дремлющий сержант белорусского РХБЗ. Статья коротенькая, почти без воды, но может так оказаться, что жизненно важная (=«закладочная», FAQ по метанолу)! За противоядием — идем под кат.

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

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

При работе над мессенджером для корпоративных коммуникаций Kato.im мы уделили много внимания проблеме достижимости собеседников и снижению объёма информационного шума.

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

В данной статье будет раскрыта тема востребованности специалистов по информационной безопасности, специфика требований и навыков.

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

Работать в ИТ — круто, но путь в индустрию может быть совсем не таким, как описывают родители или преподаватели в школе. На биржах труда ищут мобильных разработчиков, девопсов, бэкендеров и фронтендеров, но где эти профессии в списках специальностей классических вузов?

Мы запускаем цикл статей в которых подробно расскажем о каждой профессии через опыт людей. В первом выпуске обсуждаем Python-разработчиков. Свои истории рассказали Артем Сухаренко и Данила Лобанов. Они пришли в профессию совсем недавно, но успели набраться опыта в других сферах. А экспертом выступил Алексей Петренко — декан факультета Python в Geekbrains.

Мы поговорили о том, что нужно знать перед обучением, чем хорош и плох язык, что трудного ждет в обучении и на чем стоит сосредоточиться; какие профессии и деньги сулит знание языка, как готовиться к первым собеседованиям и многое другое.

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

Вот что входит в его обязанности (обобщённо) в избыточном варианте:

Часть 2
3.2._sparsechunk-файлы.
4.Создание dat-файлов.
5.Источники информации.

Структура образов разделов, содержащих файловую систему.

1.Введение

Образы разделов мобильных устройств (МУ), содержащих файловую систему (ФС) ext4, имеют большие размеры, например, размер образа раздела system может достигать нескольких ГБ, а размер образа раздела userdata составляет уже несколько десятков ГБ.

Эти особенности требуют от разработчика прошивок применения «хитростей» при выполнении операций первоначальной загрузки прошивок МУ или установки обновлений, т.к. размеры образов разделов становятся не только соизмеримыми с объемом оперативной памяти МУ, но и значительно их превышают.

Разработчики стоковых (заводских) прошивок для уменьшения размера образов разделов в настоящее время применяют следующие способы:

• разделение (разрезание) образа на части (chunks);
• сжатие образа целиком;
• использование dat-файлов.

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

Интроверты — застенчивы, молчаливы и замкнуты в своём мирке. Экстраверты дружелюбны, открыты, всегда готовы к общению. Это мнение обывателя.

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

Для начала об авторе – я более 20 лет проработал в ИТ в трех компаниях: EMC, IBM, Sun (в алфавитном порядке). Начинал как системный инженер сразу после университета, потом был старшим инженером, техническим консультантом, руководителем технических консультантов и, наконец, техническим директором, руководившим командой пресейлов и архитекторов всего более 70-ти человек. Кроме того, год я был лидером продавцов через партнеров (Channel Sales Leader), распределенных по Центральной и Восточной Европе. Ниже я попытаюсь поделиться своим опытом именно, как руководителя и, дабы не возникало не правильных или не нужных ассоциаций, я буду приводить примеры из практики во время работы на компанию ABC (тоже три буквы). Возможно, изложение несколько однобоко, поскольку все мои работодатели – крупные международные компании, и я работал в их региональных офисах. Ну, тогда с этой спецификой я не могу ничего поделать и то, что читатель сочтет не приемлемым и не правильным пусть и останется таковым персонально для него.

Я работаю ПМом в небольшой – порядка 50 человек – компании по разработке софта. Данная статья написана исключительно с целью – поделиться своими мыслями по поводу процессов управления людьми в команде и, в идеале, услышать комментарии профессиональных руководителей и разработчиков. Сразу оговорюсь, что я не затрагиваю другие аспекты управления
Поскольку работаю весьма недолго, около года, а до этого был программистом (прошёл все ступени от стажёра до архитектора), то в памяти ещё свежи те ошибки, которые осуществляли мои руководители, после которых, в лучшем случае, на душе становилось пакостно. Опять же, дисклеймер, написано всё это исключительно с целью обсуждения… Итак, начнём.

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

Именно о том, что всегда должно быть сделано при выполнении проекта мы и поговорим на неожиданном примере трансатлантического яхтенного перехода.

Тем кто когда либо заказывал разработку дизайна чего либо будь то сайт, лого, буклет и так далее, или делал по заказу подобное, должна быть знакома эта точка в проекте — «утверждение дизайна». Зачастую самая болезненная. Причины бывают разные, и одна из самых распространенных — неправильный выбор заказчиком критериев годности дизайна, и как следствие неверная постановка задачи, а результат — сорванные сроки, испорченные отношения, потерянные деньги и так далее. Вот об этом и напишу, как этот кошмар превратить в праздник ;)

Самые распространенные ошибки заказчика

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

Диаграммы Ганта. Визуализируй это!

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

Одним из наиболее удобных и привычных способов визуализировать процесс разработки являются диаграммы Ганта. Они могут пригодиться не только для проектирования процесса разработки ПО. Хотите спланировать постройку дома? Не вопрос! С их помощью можно визуализировать даже ваш любимый рецепт домашней лазаньи!

Минимум инструментов для максимально успешных результатов — именно такому правилу следуют настоящие специалисты. К примеру, динамично развивающаяся сфера управления проектами избирательно подходит к используемым в работе техникам и методикам, оставляя лишь самое полезное. Эта статья — краткий гид по знаменитой технике НЛП (нейролингвистическое программирование), которая зарекомендовала себя как одну из повсеместно используемых в психологии и бизнес-процессах.

План – это не идеальная картина, а навигация по проекту

Почему когда вы едете на машине и попадаете в только что возникшую пробку, то ваш навигатор пересчитывает маршрут и время движения по нему, а управляя проектом, вы отказываетесь от такого полезного инструмента?
Когда реальная картина на проекте складывается не так, как было запланировано, то его руководитель начинает выстраивать в голове другие маршруты и перестает ориентироваться на первоначальный план.
Уверен также, что вам знакомо следующее мнение. План – это идеальный сценарий, в действительности все бывает по-другому, поэтому ориентироваться на план невозможно. Авторы подобных тезисов под словосочетанием «план проекта» подразумевают только первоначальный план (Базовый план). Но замечу, что проект должен также иметь другой план — Рабочий план, который будет учитывать все изменения в проекте и являться вашим навигатором по проекту. Такой инструмент будет показывать вам:

• Ак туальное расписание всех задач
• Узкие места
• Прогноз завершения проекта (этапа)

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

Настройка статусов задач

Вам один раз нужно настроить программу (MS Project), используя формулы, приведенные в конце статьи, и графические индикаторы.
После чего вы сможете регулярно использовать простой и эффективный инструмент.
Итак, рассмотрим статусы задач, которые нам предстоит настроить.

Все началось с этого поста и продолжилось вот этим. Их краткое содержание:

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

Таким образом получается трехсторонний конфликт интересов:

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

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

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

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

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

Эпиграф

“Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича — я бы тогда тотчас же решилась.» Н.В. Гоголь. Женитьба.

Есть два всем известных и очень разных инструмента управления проектами: MS Project и Redmine. Каждый из них имеет свои достоинства, и эти достоинства могли бы друг друга прекрасно дополнить.

Хочу предложить вашему вниманию небольшую утилиту под названием P2R, позволяющую без всякой инсталляции и с минимумом настроек обеспечить online синхронизацию проектов в MS Project и Redmine. Она доступна по адресу.

Хотите узнать о том, что такое React, но вам всё никак не выпадает шанс изучить его? Или, может быть, вы уже пробовали освоить React, но не смогли толком понять? А может, вы разобрались с основами, но хотите привести в порядок знания? Эта статья написана специально для тех, кто положительно ответил хотя бы на один из этих вопросов. Сегодня мы создадим простой музыкальный проигрыватель, раскрывая основные концепции React по мере продвижения к цели.

Разобравшись с этим материалом, вы освоите следующее:

• Компоненты React.
  
• Рендеринг ReactDOM.
  
• Классы компонентов и функциональных компоненты.
  
• JSX.
  
• Состояние (state).
  
• Обработка событий.
  
• Асинхронный метод setState.
  
• Свойства (props).
  
• Ссылки (refs).
  

Это — практически всё, что нужно знать для того, чтобы создавать и поддерживать React-приложения.

⬝ 11 библиотек (наборов компонентов) для Angular, о которых стоит знать в 2018-м
⬝ 11 библиотек (наборов компонентов) для Vue, о которых стоит знать в 2018-м
⬝ 11 библиотек (наборов компонентов) для React, о которых стоит знать в 2018-м

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



Представляем вашему вниманию перевод первого материала из серии статей, в каждой из которых рассмотрены 11 наиболее интересных библиотек для разных веб-фреймворков, на которые стоит обратить внимание в 2018-м. Сегодня поговорим о библиотеках для React.

Сегодня мы представляем вам первую часть перевода этого большого материала. Он посвящён детальному разбору новых возможностей React, которые появились в этой библиотеке начиная с версии 16. Автор этого материала уже 5 лет занимается программированием. В прошлом он был дизайнером и пробовал себя в качестве иллюстратора. Он включил в статью комиксы, которые, по его мнению, помогут читателям лучше усвоить то, о чём тут идёт речь.

В оригинале эта статья называется «Reintroducing React: every React update since v16 demystified». Название намекает на то, что читателю, возможно, уже знакомому с React, предлагается снова познакомиться с этой библиотекой. Это повторное знакомство с React поможет ему упорядочить то, что он уже знает, и открыть для себя что-то новое.