Здесь на «Мегамозге» мы часто пишем о стартапах и их финансировании, в связи с чем у некоторых пользователей могут возникнуть оправданные терминологические вопросы. Практически в каждой статье об инвестициях в стартапы можно прочесть фразу: «СуперМегаСтартап привлек $дофига млн на стадии А». Конечно, для многих эта фраза вполне себе понятна и естественна, но когда разговор заходит до литер B, C, D и далее, многие начинают плавать, в лучшем случае отделываясь общими фразами. В этой статье я попробую все прояснить и устранить этот досадный недочет.

Добрый день, друзья! Сегодня у нас будет статья, цель которой — поделиться опытом и показать ключевые особенности и частые ошибки возникающие при проектировании и организации подсистем электроснабжения ИТ-инфраструктуры и ЦОД в целом. Но хотелось бы немного расширить аудиторию и посвятить несколько разделов базовым элементам обеспечения электробезопасности и защиты оборудования и людей. Для тех кто понимает, что такое автомат и УЗО, для чего они необходимы, что и от чего защищают – переходите к разделу Нужны ли УЗО для IT-оборудования, серверной, ЦОДа? кроме того, мы разберемся в вопросе- в каких случаях перебоев в сети питания операционная система гарантированно должна работать без сбоев. Итак…

Часть первая

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

Сейчас в издательстве ДМК-Пресс выходит русский перевод японской манги 2013 года про цифровые схемы, созданной Амано Хидэхару и Мэгуро Кодзи. Несмотря на несерьезную форму изложения, суть этой книжки очень здравая. Например, она начинает от древних микросхем малой степени интеграции и быстро привязывает их к современному языку описания аппаратуры Verilog и программируемым логическим интегральным схемам (ПЛИС). Также манга четко определяет зачем нужны комбинационные и последовательностные схемы, и дает представление о методах оптимизации.

Манга избегает ошибок многих своих предшественников. Одну из таких ошибок совершил Чарльз Петцольд в книге «Код», которая вводила последовательностную логику не на D-триггерах, управляемых фронтом тактового сигнала (edge-triggered D-flip-flop), а на D-триггерах с работой по уровню (защелках, level-sensitive D-latch), хотя потом переключалась на правильные триггеры. Вероятно, ошибка была связана с тем, что Чарльз Петзольд, который прославился как автор учебников по программированию GUI в Microsoft Windows, не был практикующим разработчиком электроники, и для него защелки были «проще», чем триггеры с фронтом. Проблема в том, что защелки плохо совместимы со статическим анализом задержек при логическом синтезе, главной технологии проектирования цифровых схем последних 30 лет. Системы на кристалле внутри гаджетов типа айфона в качестве элементов состояния в 99% случаях используют D-триггеры переключаемые по фронту, а защелки используют только в очень специальных случаях. Давать новичкам строить схемы на защелках — это значит вводить их в заблуждение.

В этом смысле манга лучше чем Петзольд. Вот как элегантно манга объясняет работу двухступенчатого master slave D-триггера, управляемого фронтом тактового сигнала. Это делается с помощью феи «Хи-хи-хи» и феи «Ха-ха-ха»:

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


Дашборд для автомобилиста

Цикл публикаций будет состоять из статей с описанием содержания дашбордов для веб-аналитики e-commerce сайтов. Поговорим о создании удобного интерфейса дашборда.

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

Как же все таки они устроены? И кому это может быть полезно? Вам определенно с этим следует ознакомиться, если:

1. Вы ими пользуетесь в своей торговле
2. Вы планируете написать торгового робота
3. Вы хотите реализовать торговую стратегию сами

Источник

Добрый день.

Я уже очень давно не рассказывал о своем проекте FLProg. Последний пост был ещё на Geektimes.
Пора исправить это безобразие. С этого поста я начинаю серию уроков по использованию новых возможностей программы.

Если Вы не знакомы с проектом, можно посмотреть его историю в блоге.

Сейчас на сайте программы ведётся тестирование предрелизовой версии с номером 3.1.4. Начиная с версии 3.1, в программе появилась поддержка контроллеров ESP8266 как полноценного контроллера.

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

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

Мы публикуем перевод материала Александра Савченко, сотрудника компании Django Stars. Он рассказывает, как оценивать стоимость создания мобильных приложений, учитывая как прямые, так и косвенные статьи расходов.

Определение стоимости разработки конкретного приложения — важная задача как для компании, так и для программиста, который работает самостоятельно. Сразу стоит сказать, что 100%-ной точности достичь вряд ли получится, но этот обзор поможет приблизиться к максимальной корректности оценки.

Привет, Хабр! Меня зовут Володя Зимин, я — и.о. дизайн-директора в Альфа-Банке. Несколько дней назад, 23 августа, коллеги из МегаФон у себя в офисе провели полезный митап, на котором мы обсуждали CJM.

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

CJM позволяет увидеть эти места, провести необходимые исследования (это важно), а затем пофиксить всё, что стоит пофиксить.

Мой доклад назывался «Как использовать потенциал CJM по-максимуму: типичные ошибки, совершаемые UX-дизайнерами и продакт-менеджерами — экспертный взгляд изнутри».

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

Под катом — видео с докладом (а также с докладами коллег из МегаФона, Octoberry и Boston Consulting Group) и презентации.

Изучать Python3 я начал с документации на официальном сайте. Мне понравились примеры кода, но, к сожалению, они были там не интерактивными. Хотелось попробовать выполнить код самостоятельно, с разными входными данными и посмотреть на выводимый результат. Так же мне лично легче запоминаются конструкции языка, если я их набрал несколько раз вручную. Python консоль для этого подходит отлично, но хотелось так же иметь своего рода шпаргалку, к которой можно было бы вернуться при написании программ в дальнейшем, если, например, возникнет вопрос, как в Python-е написать цикл for и т.п. И последней каплей стало желание автоматической проверки стиля написания кода в соответствии с существующими стандартами. Читать и вникать в них было лень, поэтому хотелось чтобы проверка кода была автоматической и подсказывала какие ошибки я делаю и как их исправить.

В итоге все свои эксперименты я вылил на GitHub.

Мировой рынок IT стремительно развивается. С каждым годом профессия разработчика софта становится все более востребованной — уже в 2017 году в мире насчитывался примерно 21 миллион программистов различных направлений.

К сожалению, русскоговорящий рынок IT находится еще на начальной стадии развития — уже есть крупные и успешные проекты, но рынок еще долго не сможет сравняться с европейским и американским, которые производят до 85% всех IT-продуктов мира.

Всем привет! Меня зовут Михаил Берёзин, я — тимлид в HFLabs. Мы делаем очень сложный enterprise-софт для банков, сотовых операторов, страховых компаний, ритейлеров.

Полгода назад мы совершили большую ошибку: набрали в команду сразу 8 человек, штат вырос в 2 раза. Раньше никогда не брали так много людей скопом, поэтому забуксовали с онбордингом новичков. Расскажу, как справились с проблемой.

От переводчика: оригинал статьи написан Александром Шапородом для блога его компании Django Stars. Они разрабатывают мобильные приложения, а своим опытом делятся с читателями.

Аутсорсинг в ИТ имеет ряд достоинств: например, он позволяет экономить средства и при необходимости получать помощь экспертов в тех или иных областях. Тем не менее есть и проблемы, риски, которых избежать очень сложно, если вообще возможно. Но если о них знать, то можно значительно снизить их влияние. Как? Об этом и поговорим.

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

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



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

У разработчика, который впервые столкнулся с генерированием электронных писем, практически нет шансов написать приложение, которое будет делать это корректно. Около 40 % писем, генерируемых корпоративными приложениями, имеют те или иные нарушения стандартов, и, как следствие, проблемы с доставкой и отображением. На это есть причины: электронная почта технически гораздо сложнее, чем веб, работа почты регулируется несколькими сотнями стандартов и несчетным количеством общепринятых (и не очень) практик, а почтовые клиенты отличаются разнообразием и непредсказуемостью. Тестирование может заметно улучшить ситуацию, но материалов, посвященных тестированию почты, практически нет.

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

• Какие бывают электронные письма
• Кто участвует в процессе тестирования и контроля
• Почтовое сообщение и почтовый транспорт
• Интерфейс почтовой инфраструктуры и границы тестируемого приложения
• Определение тестируемых параметров
• Типичная структура генерирующего приложения
• Что и когда тестировать
  
  1. Инфраструктура доставки
  2. Генерирующее приложение
  3. Структурный и вёрсточный шаблоны письма
• Базовые требования при проверке инфраструктуры
• Требования к авторизации
• Проверка генерирующего приложения
  
  • Требования к почтовым адресам
  • Требования к заголовкам писем
  • Требования к структуре письма
  • Требования к URI
  • Требования к вёрстке письма
• Проведение сплит-тестов

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

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

10 лучших инструментальных средств тестирования интерфейсов прикладного программирования 2018 года.

Интерес к тестированию неудержимо растёт на протяжении нескольких последних лет, согласно исследованиям Google Trends. Опрос, проведенный компанией Smartbear в 2017 году среди 5000 профессионалов в области разработки программного обеспечения, показал, что более 50% опрошенных респондентов используют автоматические средства тестирования API, и ожидается рост их количества на 30% ( с 59% до 77%) в течении следующих двух лет, причем 80% участников опроса указали, что отвечают за тестирование API.

Привет, как вы уже поняли, это продолжение моей истории реверс-инжиниринга и портирования «Нейроманта».

Реверсим «Нейроманта». Часть 1: Спрайты
Реверсим «Нейроманта». Часть 2: Рендерим шрифт
Реверсим «Нейроманта». Часть 3: Добили рендеринг, делаем игру

Сегодня начнём с двух хороших новостей:

• во-первых, я больше не один — к проекту присоединился и уже успел внести ощутимый вклад пользователь viiri;
• во-вторых, теперь у нас есть открытый репозиторий на github.

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

Предисловие от автора, Рича Тёрнера из Microsoft. Это статья о командной строке: от её появления и эволюции до планов капитального ремонта Windows Console и командной строки в будущих версиях Windows. Будь вы опытным профессионалом или новичком в IT, надеемся, что вы найдёте статью интересной.

Давным-давно в далёкой-далёкой серверной...

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

Одним из первых по-настоящему эффективных человеко-машинных интерфейсов стал Tele-Typewriter или «телетайп». Это электромеханическая машина с клавиатурой для ввода данных и каким-нибудь устройством вывода — сначала использовался принтер, позже экран.