Небольшая история, как из пробного проекта вырастить приложение, которое охватывает большую часть деятельности ИТ отдела.

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

С чего все началось? Давным-давно придя в организацию, в которой до сих пор работаю, я столкнулся с проблемой, что ИТ отдел совершенно не занимался учетом аппаратного обеспечения. Существовала база 1С бухгалтерии, в которой ставились на учет системные блоки, мониторы, принтеры и прочее оборудование. Кладовщик рисовал инвентарные номера и на этом все заканчивалось. Сотрудники отдела получали новую технику, настраивали, устанавливали и дальше о том где какая техника знал только кладовщик и то не всегда. Ситуация более чем странная, во всяком случае для меня.

Меня зовут Андрей Булов. Я простой питерский технарь, архитектор, разработчик, DevOps технический менеджер. Сейчас работаю в Quantori.

Я не буду описывать самоорганизующиеся команды, а расскажу про алгоритм их создания. Это мой личный опыт — я так работаю с командами (их было 30+). Он перекликается с Management 3.0, моделью Херши-Бланшар, LeSS, Sсrum и даже SAFe, а также со многими другими софтовыми областями. И в нем есть конкретика на уровне действий.

Для ленивых: я исследую окружение, проектирую дизайн культуры, объясняю правила и делегирую задачи команде. Я не поддерживаю внедрение самоорганизации через фреймворк. Видео моего выступления об этом на конференции TeamLead Conf 2021 можно посмотреть здесь.

Как архитектор-консультант в Red Hat, я имел возможность поработать над множеством проектов для наших клиентов. У каждого из них есть свои особенности, которые, однако, имеют некоторые общие черты. Большинство клиентов хотят знать, как скоординировать запись в несколько систем одновременно. Ответ на этот вопрос обычно включает подробное объяснение двойной записи, распределенных транзакций, современных альтернатив, а также возможных сценариев сбоев и недостатков каждого подхода. Как правило, именно в этот момент заказчик понимает, что разделение монолитного приложения на микросервисы - долгий и сложный путь, обычно требующий компромиссов.

• 0 (вводная часть). Зачем мы здесь собрались. Краткая история GPGPU.
• 1. Пишем для OpenCL.
• 2. Алгоритмы в условиях массового параллелизма.
• 3. Сравнение технологий.

CPU — в помойку?

Функциональное программирование может отпугивать сложностью и непрактичностью: «Я далек от всех этих монад, пишу на обычном C#, в докладе про функциональщину ничего не пойму. А если даже напрягусь и пойму, где мне потом это применять?»

Но когда объясняет Скотт Влашин, все совершенно не так: его доклад о композиции с конференции DotNext 2019 Moscow — пример того, как можно доносить функциональные идеи простыми словами. Он за час перешел от бананов к монадам так, что второе кажется немногим сложнее первого. А в конце объяснил, почему осмыслить композицию полезно даже тем, кто не собирается покидать мир ООП. Примеры кода в докладе как на F#, так и на C#.

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

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

Журнал SD Times назвал 2021 годом low-code и рассказал, почему программисты боятся этих решений, как low-code инструменты помогают бизнесу в пандемию, снимают нагрузку с IT-отделов и превращают обычного сотрудника в разработчика. Не обошлось и недостатков — такие системы подходят не всем компаниям. Предлагаем адаптированный перевод статьи на русский язык.

Год назад никто не думал, что бизнесу придется срочно переходить из офлайна в онлайн. Люди ушли из офисов и начали работать из дома — компаниям понадобились новые приложения, чтобы управлять проектами, выполнять заказы и работать с клиентами. Новые приложения нужны были срочно, а обычная разработка не поспевала за спросом. Помогли low-code-платформы, где можно собирать приложения без кода.

• в непредсказуемости сроков разработки
• большим временем локализации ошибок
• увеличением требования к квалификации разработчиков и сложной заменяемости

Несколько лет назад, для закрытия одного их предметов мне довелось перевести данный букварь. Де-факто этот вариант стал официальным переводом. Но развитию этого перевода мешает, тот факт, что он был написан в Google Drive и закрыт на редактирования. Сегодня я уделил время на переформатирования всего этого текста в MD формат с помощью редактора Хабра, с радостью публикую здесь и вскоре отдам текущим контрибьюторам.

Словарь

Node — нода — узел с каким либо ресурсом
Content — контент — данныe
Traffic — трафик — запрос/ответ, данные которые передаются от сервера клиенту и наоборот
Hardware — железо — аппаратная часть
Instance — инстанс — созданный объект какой либо сущности. Например инстанс сервера API
Headers — хедеры — заголовки (как правило TCP пакета, но может быть и HTTP запроса)

<canvas width="300" height="300"></canvas>

const width = canvas.width = innerWidth
const height = canvas.height = innerHeight

const canvas = document.querySelector('canvas')
// не путать с объектом jQuery
const $ = canvas.getContext('2d')

Всем привет!


Меня зовут Александр Бальцевич, я работаю на лидерской позиции Web-команды проекта Gem4me. Проект представляет из себя инновационный месенджер для всех и каждого (пока в моих фантазиях, но мы стремимся к этому ;-) )

Коротко о стэке веб-версии: ReactJS (кто бы сомневался) + mobX (лично я вообще не в восторге, но мигрировать никуда не планируем; если интересны детали, в чем именно не устраивает, пишите комментарии — возможно сделаю про это отдельную статью) + storybook + wdio (скриншотное тестирование).

Предисловие переводчика

Введение

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

Когда я попробовал сделать это первый раз, был неприятно удивлен собой. Мое "простое и понятное" объяснение превратилось в занудство, в рамках которого четко прослеживалась отчаянная попытка объять необъятное и рассказать в двух словах обо всем понемногу. Нужно ли говорить, что такой рассказ скорее не заинтересует, а напугает Вашего собеседника, попутно уменьшив желание сделать что-то свое, даже если раньше в планах был небольшой калькулятор.

Не секрет, что в Интернете размещено огромное количество статей на эту тему, но в моем случае повествование будет немного отличаться: здесь будет только наглядная практика, без определений и прочих деталей. То есть смотрим — видим — комментируем происходящее. Смотрится, на мой взгляд, все достаточно просто и наглядно, куски кода получились тоже небольшие и очень простые, готовые к быстрому использованию в собственном проекте. Мне кажется, такой подход дает достаточно широкую обзорную картину классических инструментов Android, и при написании первого приложения вместо вопросов "что мне использовать" будут более конкретные вопросы "как именно мне использовать компонент Х". А уже все подробности об этом человек сможет узнать сам — если захочет.