Research'n'Destroyer
Make QR Codes Great Again или камерная революция от Apple
На недавнем WWDC Keynote Крэйг Фидеричи мельком анонсировал нативную поддержку QR-кодов в iOS11. Новость эта прошла почти незаметно. А зря.
Под катом расскажем: ностальгически о прошлом QR-кода, обстоятельно – о настоящем и, вангуя, – о ближайшем будущем. А еще о том, почему нас, людей разрабатывающих продукты, чтобы смешить других, так с этого прёт.
Вы — не Google
Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.
Вот как комментировал этот выбор Joe Hellerstein своим студентам (на 54-той минуте):
Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»
Сколько этажей в вашем датацентре? Google сейчас строит четырёхэтажные, как вот этот в Оклахоме.
Откуда берётся стремление к чрезмерной заботе о детях
Когда мне было шесть лет, мой район служил идеальной площадкой для активного и идиллического детства. На той же улице жило полдесятка моих сверстников, и мы быстро образовали свою детскую банду. Дни напролёт мы строили рампы для велосипедов, играли с мячом у меня во дворе и просто шатались по округе.
Мой район в то время ещё только застраивался, поэтому у нас было множество недостроенных домов для изучения. Когда строители покидали стройку по окончанию рабочего дня, мы на велосипедах ехали, чтобы посмотреть на то, что они успели сделать, и полазить по каркасам домов, вырастающих из покрытых грязью участков. Интереснее всего было исследовать двухэтажные дома. Нужно было взбираться по лишённым перил, недоделанным лестницам, чтобы наверху иметь возможность походить по балкам и покидаться вещами в своих приятелей.
Всё плохо
Что ж, всё плохо. Немного забавно так говорить: на конференции (Web à Québec) было много разговоров об удивительном будущем и вещах, возможных благодаря новым технологиям. О новых средствах и устройствах, которые должны сделать нашу жизнь проще. Мои знакомые знают, что у меня обычно очень циничный взгляд на технологии; лично я боюсь всех этих умных устройств, которые реагируют на мои слова, чем восхищались другие спикеры.
В основном потому, что чем больше времени я трачу на программирование и провожу в этой отрасли, тем больше узнаю, как всё работает изнутри, и тем меньше доверия всё это мне внушает. Я подобрал изображение для слайда. Это картина «Триумф смерти» Питера Брейгеля. В некоторой степени она раскрывает моё отношение к «умному дому».
Как мотивировать пользователей залипнуть в вашем продукте навсегда: Фреймворк Папы Григория
Хотелось бы сказать, что я сейчас поделюсь с вами своей уникальной разработкой, но на самом деле она никакая не уникальная и ей не одна сотня лет.
Я предпочитаю название Фреймворк Папы Григория. Вам его составляющие наверняка знакомы как семь смертных грехов. Семь главных грехов. Peccata capitalia.
Давайте посмотрим как успешные приложения умело их используют и позволяют предаться всем им одновременно.
Папа Григорий в своем труде «Толкование на Книгу Иова, или Нравственные толкования» (Expositio in librum Iob sive Moralia) упорядочил их от самых простых в реализации, но привлекающих не всех, до самых сильных, над которыми, однако, надо потрудиться.
Остроумие и отвага: как мы много раз ошибались, создавая iFunny
Это — не статья, это — фейлбук. То, что вы прочтете под катом, — выжимка наших нелепых техно-промахов за все 5 лет работы над флагманским продуктом — iFunny. Возможно, наша фейловая история поможет вам избежать ошибок, а возможно, вызовет смех. Что тоже хорошо. Смешить людей — призвание FunCorp уже 13 лет.
Гайд по Pascal: разбираемся в видеокартах NVIDIA 2016 года
Новое поколение железа в лице GTX 1080 и 1070 буквально похоронило результаты прошлогодних систем и рынок флагманского б/у железа, а «младшие» линейки в лице GTX 1060 и 1050 закрепили успех в более доступных сегментах. Владельцы GTX980Ti и прочих Titan’ов рыдают крокодильими слезами: их убер-пушки за много тысяч рублей разом потеряли 50% стоимости и 100% понтов. Сама NVIDIA заявляет, что 1080 быстрее, чем прошлогодний TitanX, 1070 легко «наваляет» 980Ti, а сравнительно бюджетная 1060 сделает больно владельцам всех остальных карточек.
Так ли это, откуда растут ноги высокой производительности и что с этим всем делать в преддверии праздников и внезапных финансовых радостей, а также чем именно себя порадовать, можно узнать в этой длинной и немного занудной статье.
KPI, или пособие по командному самоубийству
- 68338 километров на поездки.
- 72 человеко-часа на почтовую переписку.
- 423 человеко-часа на эксперименты с коллективом в 30 человек.
- 88 часов на подготовку докладов и выступления на конференциях.
- 17 чашек кофе на беседу с мудрыми людьми на афтепати.
- Порядка 25 часов на набор этого текста и правку багов в нем :).
- До смерти замученный копирайтер, который был вынужден разбирать мои черновики, аудиозаписи и вообще ему спасибо.
Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.
Рано или поздно, наверное, у каждого директора возникает желание платить по справедливости. За выполенную работу. И очень многие сейчас пытаются внедрять KPI (ключевые показатели эффективности). Работает так: вы, как владелец бизнеса, назначаете конкретные цели для сотрудников. Они достигают или не достигают поставленных целей в процессе работы. Тем, кто достиг — выдается плюшка (денежная премия).
Смысл такого подхода: платить по справедливости. На сколько наработал — столько и получил. Это честно, это логично, это — прекрасно!
Ну, логично же, что:
- Продажникам нужно назначать процент с оборота. Волки должны быть голодными. (Да, есть альтернативное мнение, что применить такой подход — значит «обложить себя дополнительным налогом». Но как по мне — тут все справедливо :-)).
- Офисному планктону — ставить оклад. Стабильность для них — ооочень важное условие существования.
А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.
Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:
Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.
Музыкальная теория для гиков
Я ничего не знаю о музыке. Я знаю, что в музыке есть знаковые обозначения, но иногда у них вырастают закорючки. Я знаю, что увеличение октавы удваивает высоту звука. Я знаю, что для того, чтобы написать песню в стиле поп достаточно всего четырех аккордов. Вот, пожалуй, и все.
Все остальные правила для меня выглядят совершенно, ну просто абсолютно произвольно. Почему у нас есть 12 нот, но для их обозначения применяются только 7 букв? Откуда взялись знаки при ключе? Почему ни одну статью по музыке в Википедии просто невозможно понять, не прочитав сперва все остальные?
Стилизация изображений с помощью нейронных сетей: никакой мистики, просто матан
Приветствую тебя, Хабр! Наверняка вы заметили, что тема стилизации фотографий под различные художественные стили активно обсуждается в этих ваших интернетах. Читая все эти популярные статьи, вы можете подумать, что под капотом этих приложений творится магия, и нейронная сеть действительно фантазирует и перерисовывает изображение с нуля. Так уж получилось, что наша команда столкнулась с подобной задачей: в рамках внутрикорпоративного хакатона мы сделали стилизацию видео, т.к. приложение для фоточек уже было. В этом посте мы с вами разберемся, как это сеть "перерисовывает" изображения, и разберем статьи, благодаря которым это стало возможно. Рекомендую ознакомиться с прошлым постом перед прочтением этого материала и вообще с основами сверточных нейронных сетей. Вас ждет немного формул, немного кода (примеры я буду приводить на Theano и Lasagne), а также много картинок. Этот пост построен в хронологическом порядке появления статей и, соответственно, самих идей. Иногда я буду его разбавлять нашим недавним опытом. Вот вам мальчик из ада для привлечения внимания.
Принципы и приёмы обработки очередей
Принципы и приёмы обработки очередей
Константин Осипов (Mail.ru)
Как вы считаете, какова стоимость очередей с приоритетами? То есть если кто-то лезет вне очереди, то как посчитать стоимость для всей системы в этой ситуации, чему она пропорциональна? Времени обслуживания клиента — например, 5 минут стоит его обслужить? Она пропорциональна количеству ожидающих, потому что время ожидания для каждого из них увеличится.
Для начала о себе — я занимаюсь разработкой СУБД Tarantool в Mail.ru. Этот доклад будет об обработке очередей. У нас много очередей внутри системы, фактически вся база данных построена как система массового обслуживания.
В основном речь будет идти о проблемах балансировки нагрузки, но перед этим я хотел бы поговорить о том, зачем нужны очереди и как они появились именно в компьютерных системах, чего они позволяют добиться.
Как мы делали мониторинг запросов mongodb
Использование монги в production — достаточно спорная тема.
С одной стороны все просто и удобно: положили данные, настроили репликацию, понимаем как шардировать базу при росте объема данных. С другой стороны существует достаточно много страшилок, Aphyr в своем последнем jepsen тесте сделал не очень позитивные выводы.
По факту оказывается, что есть достаточно много проектов, где mongo является основным хранилищем данных, и нас часто спрашивали про поддержку mongodb в окметр. Мы долго тянули с этой задачей, потому что сделать "осмысленный" мониторинг на порядок сложнее, чем просто собрать какие-то метрики и настроить какие-нибудь алерты. Нужно сначала разобраться в особенностях поведения софта, чтобы понять, какие именно показатели отслеживать.
Как раз про сложности и проблемы я и хочу рассказать на примере реализации мониторинга запросов к mongodb.
Типичные ошибки начинающего технического директора в ИТ — мнения экспертов
Изображение с сайта tech.co
От некоторых сотрудников ИТ-компаний до сих пор можно услышать такую реплику: «Я не совсем понимаю точное значение должности Технический директор». Как отметил в предельно простой форме один из пользователей «Тостера», «CTO — технический человек, который что-то понимает в бизнесе». Если рассматривать это понятие чуть шире, то можно сказать, что он балансирует на стыке между разработкой ИТ-продуктов с командой технических специалистов и принятием бизнес-решений совместно с менеджерами.
Соответственно, для специалистов, желающих занять позицию технического директора в ИТ, существует, как минимум два пути:
- стандартный — «Developer -> Senior -> Team lead -> CTO»;
- гуманитарный – «PM -> Senior PM -> CTO».
Безусловно, в случае второго варианта понимать технические нюансы техническому директору может быть сложнее.
Но достигнув желаемого, в целом, опытный специалист переходит как бы в разряд начинающих. Он становится этаким Junior-CTO и сталкивается с новыми вызовами.
О том, какие ошибки и подводные камни ожидают новоиспеченных технических директоров в ИТ-сфере, мы попросили рассказать экспертов отрасли.
Big Data головного мозга
Наверно, в мире данных нет подобного феномена настолько неоднозначного понимания того, что же такое Hadoop. Ни один подобный продукт не окутан таким большим количеством мифов, легенд, а главное непонимания со стороны пользователей. Не менее загадочным и противоречивым является термин "Big Data", который иногда хочется писать желтым шрифтом(спасибо маркетологам), а произносить с особым пафосом. Об этих двух понятиях — Hadoop и Big Data я бы хотел поделиться с сообществом, а возможно и развести небольшой холивар.
Возможно статья кого-то обидит, кого-то улыбнет, но я надеюсь, что не оставит никого равнодушным.
Демонстрация Hadoop пользователям
Чатботы: массовая истерия
Bots… Bots everywhere
Heather Rice Photography
Только ленивый сегодня не слышал, что чатботы — это будущее, а мобильные приложения скоро вымрут как динозавры. Все IT-издания возвещают о новой эпохе, а открытие магазина ботов для FB-мессенджера вообще обещало стать «самым значимым событием после открытия App Store». Похоже, пока не стало.
СМИ настолько убедительны, что невольно начинаешь задумываться о том, что надо бы уже отвыкать от красивого дизайна и полностью перемещаться в текстовую среду, где, конечно же, и одежду купить, и к доктору записаться, и деньги на другую карточку перевести будет гораздо проще.
Терзают меня смутные сомнения: почему же нажимать кнопочки в телеграме или тем более вводить "/show menu", "/choose pepperoni" — это удобнее, чем пользоваться сайтами? Понятно, что со временем платформы будут давать больше возможностей, появятся даже какие-то зачатки дизайна, но действительно ли боты убьют приложения?
Напомню, что мобильные приложения уже убили вебсайты, которые, в свою очередь, убили печатные издания, которые убили живое общение, которое убило наскальную живопись. Так почему же все убитые до сих пор так и не убились?
Каково это — быть разработчиком, когда тебе сорок
Этот пост был написан и опубликован на Medium разработчиком приложений Адрианом Космачевским из Швейцарии. Кроме подготовки перевода его публикации, я также пригласил и самого автора, Адриана ( akosma ), на Хабр, для того, чтобы он смог лично ответить на любые вопросы участников сообщества, если таковые возникнут. Думаю, для общего удобства при общении в комментариях с ним стоит использовать английский (и, при желании, дублировать на русском).
Привет всем, я — сорокадвухлетний программист-самоучка, а это моя история.
Пару недель назад я наткнулся на твит, в котором была картинка, прикрепленная ниже, и он заставил меня задуматься о моей карьере.
Эти размышления привели меня туда, откуда все начиналось.
Я дебютировал в роли разработчика программного обеспечения в 10 часов утра 6 октября 1997 года, в городе Оливос, к северу от Буэнос-Айреса, в Аргентине. Был понедельник. Не так давно я праздновал свой 24-й день рождения.
Мир в 1997 году
Тогда он был немного другим. На веб-сайтах не было предупреждений об использовании cookie. Новаторскими в сети были сайты вида Excite.com, а моим любимым поисковиком был AltaVista.
Мой электронный ящик имел вид kosmacze@sc2a.unige.ch и был расположен на личном веб-сайте, который размещался по адресу http://sc2a.unige.ch/~kosmacze. Тогда мы еще оплакивали принцессу Диану, а Стив Джобс только-только вернулся на роль CEO и убедил Microsoft «вбросить» в Apple Computer 150 миллионов долларов. Digital Equipment Corporation подала в суд на Dell, останки Че Гевары вернули на Кубу, только начался четвертый (!) сезон «Друзей». Был убит Джанни Версаче, скончались Мать Тереза, Рой Лихтенштейн и Жанна Кальман. Люди зависали за Final Fantasy 7 на PlayStation, будто бы были наркоманами, Би-Би-2 начал вещание телепузиков, а Кэмерон только собирался показать миру свой «Титаник».
Да вы задолбали своим информационным обществом
Диск с музыкой. Работает почти как AudioCD.
Предположим, вы хотите отправить срочное сообщение своему коллеге. Сегодня вы отправляете почту, сообщение в соцсети или SMS.
Спускаемся ниже по истории. Что было до этого? Факс. Он был аналогом современной электронной почты: сообщение передавалось мгновенно, вылезало из устройства и было готово к прочтению.
Идём глубже. Факса и телефона теперь тоже нет. Вы отправляете телеграмму. Как раз серьёзные телеграфные узлы были вытеснены с бэкбона телефонами. Биржи узнавали новости телеграммами. Британские журналисты из самых далёких концов света сообщали данные телетайпом. Вы могли вызвать любого человека на встречу телеграммой, которую бы отнёс специальный пацан на ваш почтовый коммутатор, а потом второй пацан – от другого локального коммутатора до адресата. Почти как сотовая сеть, только пинг больше.
Продолжаем путешествие. Отключаем электричество, появляются первые лаги, поначалу незаметные. Вот в Праге работает полноценная пневмопочта. Написали пером письмо, просушили песком и промокательной бумагой, положили в специальную капсулу. Вжух! Капсула полетела на другой конец города. Кстати, если выколупать оптику из магистрали, можно будет устроить пневмопочту в защитной трубке, так что частично обратная совместимость сохранена.
Блок-схема выбора оптимальной методологии разработки ПО
Вступление
Как выбрать методологию? Зачастую, когда необходимо принять решение о выборе методологии в голове слишком много разнородной информации и тяжело понять, что именно лучше подойдёт для проекта. В данной статье я представляю блок-схему выбора оптимальной методологии, как некую подсказку, позволяющую обратить внимание на некоторые наиболее важные аспекты.
Видео докладов Badoo с конференции Highload 2015
Если у вас появятся вопросы к докладчикам, задавайте их в комментариях. Ребята на них обязательно ответят.
1. «Near-realtime аналитика событий в высоконагруженном проекте», доклад Александра Крашенинникова
Информация
- В рейтинге
- Не участвует
- Откуда
- Лимассол, Government controlled area, Кипр
- Дата рождения
- Зарегистрирован
- Активность