Новая парадигма уже на пороге — или нет?

Согласно исследованию компании Flurry, житель США в среднем проводит за смартфоном около пяти часов в день. Эта цифра удивительна сама по себе, но, кроме того, около 65% этого времени идет на разного рода общение — социальные сети, текстовые сообщения, электронную почту и телефонные звонки. То есть, 3 часа 15 минут — каждый день.

А это значит, что все очень и очень изменилось. Хотели сделать мобильное приложение для своего крутого проекта? Ему придется конкурировать с миллионами других приложений за оставшиеся 35% времени, ежедневно уделяемого пользователями смартфону. И не забывайте сопутствующие затраты на поиски стоящей идеи.

Если не делать приложение, то какие остаются варианты? Нужно как-то строить бизнес, верно? Большинство специалистов полагают, что следующий шаг развития технологий — это чат-боты, живущие в приложениях: они расширяют функциональность более крупных платформ, таких как Facebook или Telegram, и пользователю не нужно ставить на телефон еще одно приложение. Получается взаимная выгода — если не считать разработчика, наверное. Мои сомнения насчет новомодной технологии можно было обобщить двумя пунктами:

• Написание бота бесполезно с точки зрения бизнеса.
  
• Написание ботов — невероятно сложная техническая задача.
  

Чтобы разобраться в этом вопросе, пришлось кое-что изучить. Около месяца я просто читал литературу по теме, беседовал со специалистами, игрался с инструментарием и не решался взяться за дело — но в конце концов написал работающего бота примерно за 2 часа. Все это было для того, чтобы понять, имеют ли мои сомнения под собой почву, — ну и ради удовольствия, конечно.

Переведено в Alconost

Хотите внедрить или доработать функцию поиска? Вам сюда.

Спросите разработчика: «Как бы вы реализовали функцию поиска в своем продукте?» или «Как создать поисковую систему?». Вероятно, в ответ вы услышите что-нибудь такое: «Ну, мы просто запустим кластер Elasticsearch: с поиском сегодня всё просто».

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

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

Цель статьи

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

Основываясь на опыте работы с универсальными решениями и узкоспециализированными проектами самого разного масштаба (в компаниях Google, Airbnb и нескольких стартапах), я расскажу о некоторых популярных подходах, алгоритмах, методах и инструментах.

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

Переведено в Alconost

SQL пробуждается и наносит ответный удар силам тьмы — NoSQL

С самого начала компьютерной эры человечество собирает экспоненциально растущие объемы данных, и вместе с этим растут требования к системам хранения, обработки и анализа данных. Из-за этого в последнее десятилетие разработчики ПО отказались от SQL как от устаревшей технологии, которая не могла масштабироваться вместе с растущими объемами данных — и в результате появились базы данных NoSQL: MapReduce и Bigtable, Cassandra, MongoDB и другие.

Однако сейчас SQL возрождается. Все основные поставщики облачных услуг предлагают популярные управляемые сервисы реляционных баз данных: Amazon RDS, Google Cloud SQL, база данных Azure для PostgreSQL (запущена буквально в этом году) и другие. Если верить компании Amazon, ее совместимая с PostgreSQL и MySQL база данных Aurora стала «самым быстрорастущим сервисом в истории AWS». Не теряют популярности и SQL-интерфейсы поверх платформ Hadoop и Spark. А в прошлом месяце поддержку SQL запустила и Kafka. Авторы статьи скромно признаются, что и сами разрабатывают новую базу данных временных рядов, которая полностью поддерживает SQL.

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

Переведено в Alconost

Часть 1. Новая надежда

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

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



Как так случилось? Может, наняли плохого разработчика? Кто-то ошибся в планировании проекта? А вдруг сама идея проекта была ужасной?

Возможно. Но часто проект бывает с самого начала обречен на провал из-за недопонимания одного важного момента.

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

Это предположение — неверно.

Проект — это не лист бумаги, не двумерный объект — у него есть глубина.

Каждую функцию на поверхности можно раскрыть — и так слой за слоем. Будь у меня склонность к громким заголовкам, я бы сказал, что всякое приложение — это лук, и нужно уметь правильно его чистить. Не очень понятно? Тогда давайте я поясню, что имеется в виду, и расскажу, почему не получается раскрывать слои приложения без слёз.

Переведено в Alconost

Метод, которым пользуются Джефф Безос, Уоррен Баффет и Илон Маск

Джеффу Безосу часто задают вопрос, который мы все должны задать сами себе: «Что изменится в ближайшие 10 лет?»

Это непростой вопрос: мир меняется очень быстро, и принимаемые сегодня решения определяют нашу судьбу.

Если ошибиться в выборе, можно оказаться на тонущем корабле, наблюдая, как отрасль, в которой вы решили работать, полностью обанкротилась, а приобретенные за многие годы навыки — безнадежно устарели. В таком положении в свое время оказывались миллионы людей — от журналистов до финансовых аналитиков.

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

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

За последние несколько лет я познакомился с людьми, которые свою карьеру посвятили умелому предсказанию будущего: они вкладывали деньги на основе своих прогнозов, и год за годом получали солидный куш. Я заметил, что у них есть кое-что общее — противоречащий, на первый взгляд, здравому смыслу подход к вложению денег и времени, который переворачивает вверх ногами привычные представления. В этой статье я расскажу, как можно обеспечить себе будущее, используя методы, которые применяют добившиеся всего своим умом предприниматели-миллиардеры и инвесторы, такие как Джефф Безос, Рэй Далио, Говард Маркс и Уоррен Баффет.

Переведено в Alconost

«Определение ада: «Тот человек, которым вы стали, в свой последний день на земле встретится с человеком, которым вы могли бы стать».
— Автор неизвестен

Продолжение: Рассказ о том, как не дать мне украсть номера кредиток и пароли у посетителей ваших сайтов

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

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

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

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

С этой статьи мы начинаем цикл, посвященный типичным уязвимостям, атакам и проблемным местам, присущим смарт-контрактам на языке Solidity, и платформе Ethereum в целом. В первой части мы поговорим вот о чем:

• почему сложно реализовать децентрализованную биржу на смарт-контрактах
• как сгенерировать случайное число
• как вывести из строя всю Proof-of-Authority сеть

Несколько лет назад я разрабатывал для одного большого телекома новую информационную систему. Нам приходилось взаимодействовать со всё нарастающим количеством веб-сервисов, открываемых более старыми системами или бизнес-партнёрами. Как вы понимаете, мы получили добрую порцию SOAP-ада. Заумные WSDL, несовместимые библиотеки, странные баги… Где только возможно мы старались продвинуть — и использовать — простые RPC-протоколы: XMLRPC или JSONRPC.

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

У этого перевода не совсем обычная история. Системы контроля версий далеки от моих профессиональных интересов. Для рабочих проектов они мне требовались нечасто, причем, разные, так что, каждый раз, когда возникала такая необходимость, я заново вспоминала, как в них делается та или иная операция. А для личных проектов мне хватало возможностей Dropbox, хранящей историю версий файлов.


^{Изображение из твиттера @girlie_mac}

Но вот однажды я на три незабываемых дня попала в роддом — это иногда случается с женщинами. Из развлечений у меня были новорожденная дочь и телефон с большим экраном. Дочь поначалу развлекала плохо (дома она быстро исправилась), а на телефоне помимо книг и фильмов обнаружился текст «Git from the bottom up», который оказался более чем годным… С тех пор прошло почти 3 года, подросшей дочке уже пора самой начинать использовать Git Git стал мейнстримом, если не сказать стандартом в современной разработке, а я с удивлением обнаружила, что перевода на русский этого чуда, полезного не только начинающим, но и продвинутым пользователям Git, до сих пор нет. Исправляю эту ситуацию.

В прошлой статье мы рассмотрели концептуально все слои и функции, из которых будет состоять будущая модель. Сегодня мы выведем формулы, которые будут отвечать за обучение этой модели. Слои будем разбирать в обратном порядке — начиная с функции потерь и заканчивая сверточным слоем. Если возникнут трудности с пониманием формул, рекомендую ознакомиться с подробным объяснением (на картинках) метода обратного распространения ошибки, и также вспомнить о правиле дифференцирования сложной функции.

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

Повседневные фразы и инструкции

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

Алиасинг (aliasing) — это, возможно, наиболее фундаментальный и самый широко обсуждаемый артефакт 3D-рендеринга всех времён. Однако в игровом сообществе его часто недопонимают. В этой статье я подробно расскажу о теме сглаживания (антиалиасинга, anti-aliasing, AA) в реальном времени, особенно о том, что касается игр, и в то же время буду излагать всё достаточно простым языком.

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

Эту программу можно скачать здесь.

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

В этой статье представлены три небольшие истории, которые произошли в нашей практике: в разное время и в разных проектах. Объединяет их то, что они связаны с сетевой подсистемой Linux (Reverse Path Filter, TIME_WAIT, multicast) и иллюстрируют, как глубоко зачастую приходится анализировать инцидент, с которым сталкиваешься впервые, чтобы решить возникшую проблему… и, конечно, какую радость можно испытать в результате полученного решения.

Несмотря на то, что мы предпочитаем писать про микросервисы, Kubernetes и прочее из области cloud native, нам хорошо известен и другой мир — гораздо более реальный, если посмотреть «в массе», например, на интернет-магазины (даже весьма успешные). В нём нет автоматического provisioning и масштабирования, сложной балансировки нагрузки и прочих красивых технических решений. Зато есть «Чёрная пятница», которая уже завтра, а значит — времени на подготовку практически не осталось. Конечно, наш рецепт №1 по качественной подготовке к ней (а заодно и получению целого букета дополнительных плюсов) — миграция на микросервисную архитектуру и Kubernetes, но предположим, что по какой-то причине этот вариант не подходит (до завтра его всё равно не реализовать).

Эта статья — список более-менее быстрых действий для оптимизации типовой инфраструктуры интернет-магазина (рассматриваются примеры с nginx, Apache, PHP, MySQL) с целью её подготовки к высоким нагрузкам. Они могут быть весьма очевидны для опытных системных администраторов, однако наверняка окажутся полезными для тех, кто глубоко ещё не погружался в эти вопросы, а их актуальность стремительно нарастает. Итак, попробуем выжать максимум из того, что есть в инфраструктуре, или хотя бы взять на заметку те основные вопросы, которыми стоит озаботиться перед следующими всплесками нагрузки.

Все знают о стандартной аутентификации пользователя в приложении. Это олдскульная процедура регистрации — пользователь вводит адрес почты, пароль и т. д., — а затем при входе мы сравниваем почту и/или пароль с сохранёнными данными. Если совпадает, даём доступ. Но времена изменились, и сегодня появилось много других методов аутентификации. Если хотите оставаться востребованным программистом/разработчиком в этом меняющемся, словно калейдоскоп, мире разработки ПО, то вы должны знать обо всех этих новых методах.

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

Здесь я постараюсь рассказать о большинстве распространённых сегодня методов аутентификации. Это не подробное техническое руководство, а лишь способ познакомить вас с ними. Хотя методы описаны с учётом применения в вебе, эти идеи можно реализовать и в других условиях.

Для большинства специалистов PHP не является языком, который бы всерьёз использовался для написания консольных утилит, и для этого есть много причин. PHP изначально разрабатывался как язык для создания веб-сайтов, но, начиная с PHP 4.3, в 2002-ом году появилась официальная поддержка режима CLI, поэтому он уже давно перестал быть таковым. Разработчики Badoo на протяжении нескольких лет вполне успешно используют множество интерактивных CLI-утилит на PHP.

В данной статье нам хотелось бы поделиться своим опытом работы с CLI-режимом в PHP и дать несколько рекомендаций тем, кто собирается писать скрипты на PHP, при условии, что они будут запускаться в *nix-системе (впрочем, почти всё верно и для Windows).

Есть прекрасная поговорка «И на старуху бывает проруха». Её можно сделать девизом индустрии: даже хорошо продуманная многоуровневая система защиты от потери данных может пасть жертвой непредвиденного бага или человеческой ошибки. Увы, такие истории не редкость, и сегодня мы хотим рассказать о двух случаях из нашей практики, когда всё пошло не так. Shit happens, как говаривал старина Форрест Гамп.

«Я точно не знаю, что делает этот класс, но я уверен, что это важно!»

У паттернов проектирования — типовых решений, есть антиподы — типовые ошибки в проектировании. О паттернах проектирования написано достаточно книг, о антипаттернах — единицы. Вашему вниманию представлен вольный перевод статьи с сайта SourceMaking, описывающий один из таких антипаттернов (всего на сайте в разделе Software Development Antipatterns их представлено 14).

Наименование: Poltergeists (полтергейсты)
Другие наименования: Gypsy (цыган), Proliferation of Classes (рост количества классов), Big DoIt Controller Class
Масштаб: приложение
Рефакторинг: Ghostbusting (охота за привидениями)
Причина появления: непонимание концепций ООП, лень продумать архитектуру классов