«Суть в том, что это руководство по эксплуатации IBM Model 650 было довольно глупым. Оно и подтолкнуло меня к программированию.»



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

Сегодня в блоге программы «Менеджмент игровых интернет-проектов» мы начинаем новую рубрику переводов статей по геймдизайну от иностранных экспертов. И первая статья, с которой мы хотим вас познакомить, написана по лекции директора по геймдизайну Bioware Джеймса Олена, на тему «Реалии работы гейм-дизайнером в большой студии на примере BioWare».

Не могу сказать, что я почувствовал большое воодушевление, когда мне предложили поучаствовать в проекте «Device Lab от Google», однако, без сомнения, интерес присутствовал. Когда-то я делал проект с различными взаимодействиями через Bluetooth, и у меня получились крайне интересные реализации. Однако оказалось, что в ходе манипуляций с Bluetooth все телефоны, владельцы которых по недосмотру отставили их включенными в радиусе работы Bluetooth, теряли заряд в три раза быстрее, чем обычно. Коллеги, само собой, не очень радовались. Проект пришлось закрыть. В связи с этим мне давно хотелось подержать в «цепких» руках маячки последнего поколения. И проект Device Lab мне такую возможность предоставил.


Статья автора Дмитрия Сенашенко (@DmitrySen), в рамках конкурса «Device Lab от Google».

Привет всем, продолжаю публикацию — сегодня Часть 2 истории нашей студии (нет, категорически мне не нравится слово СТУДИЯ — компания!) мобильной разработки notissimus.com, которая за 3.5 года из 3х человек сумела вырасти до 19+ человек на момент написания этих строк. Первую часть опуса можно найти по этой ссылке. Напомню, что сама история была написана давно, но сейчас мне захотелось взглянуть на нее и добавить upd.2016 — обновление и дополнения. Скажем так, ретроспективный анализ происходящего с более трезвым и опытным взглядом. Взяли за правило ежедневно записывать видео с нашим опытом работы и обзором проектов, которые ведем… вот последнее видео, которое записали сегодня — показали обороты, которая торговая компания может получить только из мобильных приложений. Ведь это всем интересно, да?)

Поехали…

p.s. часть 1 обязательна к прочтению, если вы ее не читали — запутаетесь.

Даже если вы считаете себя гиком и регулярно читаете новости технологий, уследить за всем, а тем более попробовать всё становится почти невозможно. Год назад все резко начали перископить, пять месяцев все стали ставить себе «Призму», четыре месяца назад все бросились на охоту за покемонами — заметили, кстати, что это был год трендов на букву «П»? Он, конечно, ещё не закончился, но если вы хотите оказаться на волне популярности следующими — создавайте стартапы на букву Q (или не создавайте).


— Ещё раз, мистер Бонд, мегатренды это что такое?

Для тех, кто по работе, будучи рекламщиком или запуская свой проект, должен ориентироваться в том, что сейчас модно у мобильных и интернет-юзеров, это и вовсе кошмар: если вы не ориентируетесь в том, что сейчас набирает популярность, то вряд ли успеете собрать все «сливки» от «Перископов», «Призм» и «Покемонов».

Давайте глянем на определение принципа инверсии зависимостей из википедии:

Принцип инверсии зависимостей (англ. dependency inversion principle, DIP) — важный принцип объектно-ориентированного программирования, используемый для уменьшения связанности в компьютерных программах. Входит в пятёрку принципов SOLID.

Формулировка:

A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Большинство разработчиков, с которыми мне доводилось общаться, понимают только вторую часть определения. Мол "ну а что тут такого, надо завязывать классы не на конкретную реализацию а на интерфейс". И вроде бы верно, но только кому должен принадлежать интерфейс? Да и почему вообще этот принцип так важен? Давайте разбираться.

«Героизм возникает от некомпетентности: герои нужны тогда, когда дело организовано плохо и люди не способны исполнять свои обязанности.»
— Борис Стругацкий



Должен кое в чём признаться — я не рок-звезда программирования. И не хакер. Я не владею ниндзюцу. Никто никогда не называл меня волшебником.

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

Тем не менее, каждую неделю я вижу, как ищут ниндзя-программистов, которые, полагаю, нарезают строки кода с невероятной точностью. Я читаю о технарях рок-звёздах и представляю, что они пишут такие же красивые функции, как соло “Stairway to Heaven”. Я слышу, как люди бросаются словом «хакер» (и связанными с ним «хак», «хакфест» и «хакатон»), как будто рандомно ломать что-то на кусочки или вламываться в несанкционированную систему — хорошо.

И нельзя забывать про этих потрясных волшебников, которые из ничего создают нечто с помощью своей… *магии*

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

Но что, если вы, как и я, не соответствуете этим ярлыкам?

Если вы не разделяете чувства рок-звёзд-ниндзя-хакеров-волшебников, то делаете что-то не так? Не-а.

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

Antoine Valot, эксперт по user experience из Щвейцарии, в своем блоге на Medium, опубликовал очень хорошую статью, максимально созвучную с моим практическим опытом. Решившись на адаптацию данного текста, я специально снабдил его собственными мыслями и поправками на российские реалии, так, чтобы статья не являлась бы дословным переводом, а скорее новым совместным произведением, раскрывающим некоторые секреты профессии UX.


Да, сегодня уже трудно удивить кого бы то ни было новой «очередной статьей про юзабилити», в которой в сотый раз будут сделаны все те же очевидные выводы: возлюби пользователя своего, да не будет у тебя аргументов иных кроме результатов тестирования, сотвори себе кумира из Джобса…

Привет Хабр! В 2014 году я опубликовал большую статью про наш опыт открытия студии мобильной разработки «с нуля». Хочу к ней вернуться, поделится с сообществом тем, что накипело за 2 года и привести новые цифры по оборотам, рассказать о «набитых шишках», как мы выходим на западные рынки и т.п. В России 2 года работы огромный срок, мы выросли в восемь раз за этот период времени.

Я взял исходную публикацию с 2014 года и дополнил ее (в скобках с пометкой upd.2016) новым взглядом, который поверьте за 2 года очень сильно изменился.

Итак, встречайте — часть 1:

«Андрей (Ершов), представь, как было бы здорово организовать что-то вроде паломничества, где программисты со всего мира могли бы приехать в Хорезм и отпраздновать рождение этого понятия.»
— Дональд Кнут уговаривает Ершова организовать международный симпозиум

Кнут и Ершов

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

— Я думаю, я собираюсь стать программистом.
— О, так ты занимаешься численным анализом?
— Не совсем.
— Аааа, искусственный интеллект.
— Нет, и не искусственный интеллект.
— Тогда должно быть ты занимаешься языками программирования?

«У нас вышла калифорнийская книга о математике. Книга, которая показывала неформальный стиль классов в Стэнфорде наравне с тем, что я считаю личным манифестом пути занятия математикой.»
— Дональд Кнут



«В то время была большая суматоха. Некоторые люди жаловались на то, что математика становится слишком абстрактной, что она слишком оторвана от реальности, так что я мог бы немного пошутить, назвав курс „конкретная математика“. Хотя я сказал, что слово „конкретный“ не является на самом деле антонимом абстрактного, это сочетание слова непрерывный и дискретный (CONtinuous and disCRETE).»
— Дональд Кнут

«Я всегда проводил мои занятия, почти как если бы это был языковой урок, а не информатика или математика, я адресовал вопрос студентам и они должны были выяснить, как решить эту проблему или, по крайней мере, сделать следующий шаг на пути к решению проблемы, или попробовать и потерпеть неудачу, а затем мы изучали как её исправить. Знаете, вы не найдете книг, которые описывают, как восстановиться после неудачных предположений. А так мы могли узнать как это делать в классе.»

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

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

Вот уже 11 лет я занимаюсь веб-разработкой и интернет-маркетингом. Был как на стороне заказчика, так и на стороне исполнителя. Своими руками когда-то проектировал, верстал, программировал, тестировал, продвигал, затем управлял проектами, после учил это делать других, а сейчас я их придумываю и запускаю. Единственное, что я никогда не делал своими руками — это дизайн. Другими словами, я не просто видел жизненный цикл проекта изнутри, я участвовал почти во всех этапах разработки, часто в довольно больших проектах. И вот, видя всю кухню изнутри, я постоянно наблюдаю одни и те же причины успехов и поражений. В этой статье я попытаюсь рассказать, что я увидел за 11 лет работы и более 100 стартапов, которых я касался и как же все же создать большой и успешный проект.

Прежде, чем говорить об успехе, давайте поговорим о причинах поражений, чтобы иметь возможность их избежать и тем самым повысить свои шансы на успех. Относительно недавно вышло замечательное исследование про топ 20 причин провалов стартапов. В нем описаны вроде бы очевидные вещи, о которых так или иначе думает каждый предприниматель, но если разобрать каждый пункт отдельно, то можно найти много интересных неочевидных фактов:

«Хорошие художники создают, великие художники крадут, а настоящие художники – выполняют заказ вовремя.»

The Other Half of «Artists Ship»

Пол Грэм, Ноябрь 2008

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

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



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

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

Каждая проверка имеет свою стоимость. Для примера возьмем требование о подтверждении поставщиками своей платежеспособности. Уверены, что это благоразумно? Ведь на самом деле оно ведет к существенным издержкам. Очевидны прямые потери времени людей с обеих сторон, как со стороны поставщиков, так и со стороны рассматривающих их доказательства. Но настоящие издержки именно те, о которых вам никто не скажет: компания, которая могла бы стать лучшим поставщиком, не стала участвовать в тендере из-за нежелания тратить ресурсы с учетом возможной неудачи прохождения проверки. Или которая не пройдет пороговое значение проверки на платежеспособность, которое, конечно же, будет сильно завышено, ведь реальная стоимость этой проверки так не очевидна.

Живет у меня в доме соседка: очень хорошая женщина, пенсионерка, ветеран труда, бывший медицинский работник, отработавший всю жизнь медсестрой в больнице. В настоящее время на пенсии. Я ей помогаю, чем могу, но сказ не про соседку, а про то, что подарила ей дирекция больницы, где она раньше работала планшет. Все бы ничего в этом планшете (WIFI есть, 3G нету, диагональ экрана 7 дюймов, на алиэкспрессе такие по 45 долларов с доставкой), но вот что делать с этим планшетом, естественно, не объяснили. И пришлось мне отвечать на вопрос, что делаю со своим планшетом я, а я на планшете книжки читаю, в основном Ясинского и Эльтерруса.

Естественно я подключил планшет к своему ноутбуку и перекинул апкашку CoolReader, а также свою библиотеку. К сожалению, через два дня выяснилось, что литературные пристрастия у нас разные и мои книжки соседке неинтересны. Пришлось поделиться паролем от своего вайфая и настроить opds «Флибусты», так как что такое Интернет соседка знала весьма приблизительно и ни компьютера, ни интернет-соединения у нее нет и никогда не было.

После выходных меня огорошили тем фактом, что нужные книжки с Флибусты не скачиваются. Сказать, что я был в недоумении — ничего не сказать — вся интересующая меня литература всегда была в свободном доступе, но соседка хотела Дарью Донцову и «50 оттенков серого» и, к моему удивлению, они действительно не скачивались.

Больше трех месяцев назад мы анонсировали набор в школу для Android-разработчиков в Казани, месяц назад подвели итоги отбора и пообещали после окончания Школы поделиться всеми материалами курса. Время пришло.

Что выкладываем:

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

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

В одной из команд, где я работал, мы придумали оригинальный метод для предварительной оценки задач. Метод синтезирует некоторые известные из литературы приёмы, но в приведённой форме, пожалуй, никем не описан. Концепция была следующей: объективность (связь с измеримыми показателями); интегрируемость с Agile; повторяемость; быстрота оценки (меньше 0.5% от объема задачи); доступность для начинающих разработчиков. Я буду рад обсудить нашу идею и не исключаю, что кому-то из Хабрааудитории она придётся по душе.

В этой статье я хочу рассказать о новой возможности перетаскивать данные между различными Activity в режиме совместного отображения, которая появилась с выходом Android 7 Nougat. Ранее перетаскивать данные можно было только в рамках одной Activity.

Доброго времени суток! Приближается сезон подачи заявок на стажировку в зарубежные компании и поэтому я хотел бы представить вниманию Хабрахабра статью Эрика Янга «How to Get an Internship». Она охватывает довольно большой объем подготовки к стажировке в рамках одного поста. Я старался снизить количество ошибок и опечаток, но таковые наверняка найдутся, поэтому пишите в личные сообщения.

Где-то год назад я написал в блог заметку о моем опыте участия в различных стажировках. Благодаря этому посту я стал заметнее для рекрутеров и устроился на работу в Google.

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

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