Привет! Я продолжаю про буквы для блога Текстброкера — моих хороших друзей.

Начнём с того, что сегодня, пожалуй, уже не осталось сайтов, где главная страница — единая точка входа. Это во времена Арпанета был список нод с адресами, по которым надо было ходить. Это у BBS были меню и текст на входе. Сейчас люди заходят на ваш сайт со всех сторон. Поэтому каждая значимая страница – главная. То есть к странице любого товара на сайте интернет-магазина надо относиться как к главной. И к странице услуги. И к любой другой.

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

После публикации нашего первого поста нас поздравили с выходом в «алый океан» рвущих друг друга на части конкурентов (акул бизнеса?).

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

Итак…

С каждым годом рост количества атак на веб-приложения только увеличивается. Все больше и больше случаев резонансных взломов крупных компаний и сервисов (пример взломанных компаний за последние две недели):

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

Британский оператор связи TalkTalk подтвердил факт взлома своей компьютерной системы, в результате которого злоумышленники похитили персональные данные клиентов компании. Информация включала имена, номера счетов, адреса и телефонные номера пользователей.

На компанию 000Webhost, которая является самым популярным в мире бесплатным хостингом, была осуществлена кибератака, в ходе которой скомпрометироваными оказались данные 13,5 миллионов пользователей. Похищенная информация включает в себя имена, фамилии, пароли в виде обычного текста, адреса электронной почты и IP-адреса.

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

Продолжаем перевод набора правил безопасного криптопрограммирования от Жана-Филлипа Омассона…

Предотвращайте вмешательство компилятора в части кода, критическим образом влияющие на безопасность

Проблема

Некоторые компиляторы оптимизируют операции, которые они считают бесполезными.

Например, компилятор MS Visual C++ посчитал лишним оператор |memset| в следующем фрагменте кода реализации анонимной сети Tor:

На грани: искусство крипто-хакинга или волшебство

В 2007 году в Калифорнии, по заказу властей штата, во время предвыборной компании за короткий срок были собраны несколько сильных хакерских команд, которые проанализировали применяемые системы электронных машин для голосования и, о «ужас», показали чудовищную слабость каждой из них. Поразительно, что за более чем десятилетний срок использования компьютерных систем на выборах верховной политической власти в США (номинально наиболее демократичной страны мира), оборудование для голосования официально не подвергалось всесторонней, независимой аудиторской проверке на безопасность. Изготовители предоставили полную документацию, внутренние технические описания и тексты исходных кодов программ. Срок на исследования был ограничен тремя неделями, но их оказалось вполне как достаточно для демонстрации слабой защиты всех электронных систем голосования от злоупотреблений и манипуляций голосами избирателей.

Прошло полгода с последней новости о TARS на хабре.

Напомню, что TARS — это сборщик html-верстки, основанный на gulp, в помощь любому frontend-разработчику (или даже целой команде), для создания проектов любой сложности. За последние шесть месяцев было закрыто 88 issue, выпущено 7 версий, появился CLI, так вышло, что с yeoman’ом отношения не сложились, поэтому появилась своя версия. TARS переехал в свой новый дом на github, обзавелся командой из 4 разработчиков + небольшой армией фанатов. Кстати, огромное вам спасибо за мгновенные фидбеки после релизов и не только. TARS был внедрен в нескольких вебстудиях России и за рубежом. Сборщик научил компонентному подходу не один десяток разработчиков, привлек в ряды frontend’еров тех, кто боялся всей рутины верстки. В общем, появилось много всего нового, и об этом хотелось бы рассказать.

Мартин Л. Эббот и Майкл Т. Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические проблемы масштабировании в product-группах. Список был сформирован на основе их опыта, а также в ходе коммуникаций с клиентами и лег в основу первой книги.

Архитектурные ошибки

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

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

13 предложений о стартапах

1. Выбирайте хороших сооснователей.
2. Запускайтесь быстро.
3. Дайте идее развиться (идея рождается при её реализации)
4. Поймите своих пользователей (множество успешных стартапов делали то, что было необходимо их основателям)
5. Лучше угодить нескольким пользователям, чем вызвать противоречивые чувства у многих
6. Предложите неожиданно хорошую поддержку пользователей
7. Вы делаете то, что измеряете (измерение чего-либо странным образом приводит к его улучшению)
8. Тратьте немного
9. Добейтесь небольшой прибыли (достаточно, чтобы прокормить основателей)
10. Избегайте отвлечений (особенно тех, за которые платят, как за работу; и ещё консультирование)
11. Не поддавайтесь деморализации
12. Не сдавайтесь
13. Сделки срываются

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

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

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

Флагманским продуктом в этом направлении стало приложение для создания и управления базами данных для Android устройств.

Все статьи, прочитанные на эту тему (а их было немало), англо- и русскоязычные, в один голос утверждали, что необходимо в первые дни после публикации (1-3 дня) нагнать как можно больше посетителей на вашу страничку в магазине и заставить посетителей установить приложение. Приложение, показавшее быстрый рост в первые дни после публикации, привлекает внимание издателей, и есть шанс, что оно попадет в список Featured Apps в своей категории или даже в целом в магазине, что несомненно принесет еще больше пользователей и, как следствие, прибыли (вы же для этого разрабатывали свое мобильное приложение). Такая стратегия была оправдана, когда приложений в магазине было не так много и новые появлялись не со скоростью света.

Результат такого подхода выглядит примерно так:



Эффект кратковременный, и если за 3 дня вы не попали в желаемый список Featured apps, считайте, что усилия и затраты не оправдались. Количество установок неминуемо снизится в разы.

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

В античной Греции труд считался недостойным граждан занятием. Для этого были рабы — а граждане могли посвятить себя искусству, наукам и войне. Определённая логика в этом была — по крайней мере, именно эллины основали фундамент всей современной западной цивилизации.

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


Перевод сервиса smartprogress.do специально для «Мегамозга»

Когда Google купил онлайн-редактор фотографий Picnik в 2010 году, глава отдела маркетинга Лиза Конкергуд [Lisa Conquergood] и остальная команда проекта перешли в Google вместе с ним. Они продолжали работу до закрытия проекта в 2012 году. После этого команда ушла из компании и основала новый сайт для редактирования фотографий PicMonkey.

Однако у Конкергуд был шанс прочувствовать продуктивность и схему работы одной из успешнейших компаний в мире. «Миссия Google – организовать всю информацию мира»,- утверждает она. «Они и внутри компании занимаются тем же самым».

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

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

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

«Офисы Google разбросаны по миру»,- говорит Конкергуд. «Очень важно уметь легко собирать вместе множество людей. Телефонные конференции лишены возможности демонстрации слайдов. Google Hangouts были созданы специально для этого».

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

Мы постоянно работаем над тем, чтобы IaaS был простым и понятным даже для тех, кто не сталкивался с ИТ-сферой. Для этого мы проводим оптимизацию всех систем и рассказываем о своем опыте в нашем блоге на Хабре.

Пара примеров:

• «Удобный хостинг»: Предустановка панели управления и дозаказ лицензий на лету
• Как работает API нашего IaaS-провайдера
• Как мы разработали свой DNS-менеджер

Сегодня мы поговорим о том, как ускорить загрузку страниц, и взглянем на советы эксперта по Ruby Нейта Беркопеца (Nate Berkopec).

Подробно о преобразовании асинхронного кода, осуществляемого компилятором

Механизм async реализован в компиляторе C# при поддержке со стороны библиотек базовых классов .NET. В саму исполняющую среду не пришлось вносить никаких изменений. Это означает, что ключевое слово await реализовано путем преобразования к виду, который мы могли бы написать и сами в предыдущих версиях C#. Для изучения генерируемого кода можно воспользоваться декомпилятором .NET Reflector или ILSpy. Это не только интересно, но и полезно для отладки, анализа производительности и других видов диагностики асинхронного кода.

Про то, что такое Scrum и с чем его едят написаны миллионы статей. Однако большинство из них предполагают, что до скрама существует некий вакуум, либо наоборот жесткая среда с ведением процессов по PMBOK и др. Множество авторов пишут про «нулевой спринт» в начинающимся проекте, про подбор идеальной команды, про выбор длины спринта, однако в свое время я не нашел большого количества статей про внедрение Agile методологий в существующую среду, в которой до этого не было методологий, но уже были сложившиеся традиции.

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

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

Январь 2005
(Я написал эту речь для выступления перед выпускниками школы. Мне не удалось с ней выступить, так как школьная администрация запретила меня приглашать.)

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

«Эх, еще бы вокруг шарика махнуть…»

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

Как и любая кардинальная смена обстановки, переход на удаленную форму работы сопряжен с большим числом вопросов и подводных камней. Пожалуй, к самым важным вопросам можно отнести следующие:

• Где найти эту самую удаленную работу?
• Что необходимо знать и уметь?
• Сколько получают сотрудники на удаленной работе?

Мы тоже решили заняться поисками ответов на эти вопросы. В итоге наша любознательность переросла в весьма познавательное исследование. Интересно? Тогда добро пожаловать под кат!

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

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

Справедливости ради, надо сказать, что вопросы относительно технических интервью в свое время замечательно раскрыл Стив Йегге в своем посте 2008 года. Помимо высоких требований к знаниям базового Computer Science, там упоминались и организационные моменты — в частности, нелегкий процесс whiteboard interview и зловещий anti-loop, в который мог попасть кандидат (ситуация, когда интервьюеры, доставшиеся соискателю, никогда не смогут объективно оценить его как кандидата, и не примут его на работу по своим собственным причинам). Впрочем, на этом доступная часть информации по большей части и заканчивалась — ведь NDA не позволяло сотрудникам Google выносить сор из избы, а посторонних за кулисы никто пускать не собирался.