В этой статье я хотел бы поделиться своим опытом создания SaaS-сервиса на базе LAMP стека, Postio и доведения сервиса до состояния, когда он стал приносить 3 700 долларов ежемесячно (до обрушения рубля было почти 7 000). Сразу надо сказать, что эта история не имеет ничего общего с инвесторами, с золотой лихорадкой Кремниевой долины и с какой-то сверхсовременной технологией. Просто незамысловатая история от независимого разработчика о создании прибыльного SaaS-сервиса, который может сделать любой. Этот веб-сервис был сделан для внутреннего рынка России, поэтому я перевёл всё на английский и в доллары для удобства (пожалуйста, обратите внимание, что это перевод моей статьи, которая изначально была написана для англоязычной аудитории). Но, с другой стороны, этот опыт является довольно универсальным и может быть применён везде. По сути, это инструкция по созданию проектов такого рода.

Три года назад я решил заняться SMM, и самым простым способом сделать это показалось запустить свою собственную группу в какой-нибудь нише и попытаться развить её. Facebook был уже, мягко говоря, довольно конкурентным на тот момент, поэтому я запустил свою тестовую группу на базе «ВКонтакте». Я выбрал очень популярную нишу, потому что всё, что я хотел, — это научиться, а не доминировать на рынке.

Наверное, я должен немного отвлечься и сказать, что VK.com имел и до сих пор имеет процветающую «экосистему» таких групп, которая приносит прибыль их владельцам. Это — своеобразный рынок, который Facebook прикрыл уже давно. И этот базар является прекрасной средой для обучения и экспериментов.

В очередной статье нашего цикла публикаций, посвященного интернет-разведке, рассмотрим, как операторы продвинутого поиска Google (advanced search operators) позволяют быстро находить необходимую информацию о конкретном человеке.

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

Это — не статья, это — фейлбук. То, что вы прочтете под катом, — выжимка наших нелепых техно-промахов за все 5 лет работы над флагманским продуктом — iFunny. Возможно, наша фейловая история поможет вам избежать ошибок, а возможно, вызовет смех. Что тоже хорошо. Смешить людей — призвание FunCorp уже 13 лет.

Этим постом мы завершаем серию лекций с Data Fest. Одним из центральных событий конференции стал доклад Дмитрия Ветрова — профессора факультета компьютерных наук НИУ ВШЭ. Дмитрий входит в число самых известных в России специалистов по машинному обучению и, начиная с прошлого года, работает в Яндексе ведущим исследователем. В докладе он рассказывает об основах байесовского подхода и объясняет, какие преимущества дает этот подход при использовании нейронных сетей.


Под катом — расшифровка и часть слайдов.

Последнее время наблюдаю тенденцию, что всё больше и больше людей сталкиваются с проблемами в отсутствии геоданных. Вернее даже не так, в их закрытости. Если ещё вчера всех устраивали возможности картографических сервисов по расстановке маркеров, то теперь пользователь хочет большего: подсветить улицу, показать дома на ней, посчитать протяжённости рек и т.д. И тут их ожидает сюрприз, казалось бы на карте они всё это видят, но сделать ни чего не могут — это просто картинки. Развитие, что Google.Maps, что Яндекс.Карт остановилось на показе картинок, геокодинге, да навигации.

Введение

Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы клясться, что их службы являются RESTful. Во время собеседования вы точно услышите хотя бы несколько вопросов про REST, независимо от того это собеседования для бэкенд, мобайл или фронтенд разработчика. Я вот помню как-то во время одного собеседования меня задали такой вопрос: «Вот вы написали в своем резюме, что знайте REST․ Ответьте пожалуйста, какой HTTP код вы получите, если при запросе к RESTful сервису ресурс не найден?». Ответ 404 был принят единогласно. Если честно, я так и не понял, как этот вопрос помог понять знаю ли я REST или нет, но одно могу уверенно сказать: REST понимают далеко не все. Вот некоторые вопросы, которые мучали меня долгое время:

1. Зачем REST стал таким трендовым? Это архитектура была же предложена еще в 2000 году?
2. Что я получу если моя служба будет RESTful?
3. Как определить является ли служба RESTful или нет?
4. Как правильно должны создаваться URL REST служб?
5. Какие http методы и коды должны быть использованы в RESTful службе?

Если вы не можете дать исчерпывающего ответа хотя бы на один из этих вопросов, то продолжайте чтение. Если вы можете однозначно ответить на все эти вопросы, можете привести формат правильного URL, считайте, что GET, POST, PUT, DELETE обязательно должны соответствовать CRUD операциям с ресурсами, то вам обязательно надо продолжать чтение.

Пьеса «Технический долг» в 9 частях. Ставится и показывается впервые.

Часть 0: В пустой комнате стоят Разработчик (Р) и Менеджер (М).

М: Я собрал нас тут, чтобы рассказать пренепреятнейшее известие: система КРОТОПОН, которая работает на продакшане заглючила и мы потеряли кучу денег. Кроме того нет никого, кто знает как она работает. Поэтому (с придыханием) наш СЕО дал мне священную миссию — написать новую систему. Как ты думаешь, за два месяца справишься?

Р: А что делать-то нужно?

М: Да там немного, всего лишь пару десятков систем связать и рюшечки навесить.

Р: Эй, да это же на год работы! И вообще требования будут?

М: (В телефон) Да, конечно, за пол года справимся. (Разработчику) Ну ты тут пока начинай, а я тебе требования потом донесу.

Менеджер уходит.

Р: Но тут же…

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

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

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

От переводчика

Почитывая несколько лет назад журнал "Форбс", я наткнулся на статью, которую нашёл крайне интересной. Ну, знаете как бывает — читаешь, читаешь, и на каждом абзаце воскликаешь: «О! Це ж про меня!». Не мог поверить, что я один такой, и никто не сподобится уж если не перевести, то хотя бы сослаться на неё в русскоязычной прессе. Однако за четыре года этого так и не произошло. Ну что ж, «хочешь сделать что-то правильно — сделай это сам», посему предоставляю вниманию почтенной публики первую половину статьи. (Стараюсь переводить художественно, поэтому работа двигается небыстро; размер оригинала — больше 30 килобайт, и, «земную жизнь пройдя до половины», я понял, что держаться нету больше сил.)

P.S. Так и не смог разобраться, как поставить в заголовке тег «перевод».

Восход разработчикономики

^{Статья Венкатеша Рао опубликована в декабре 2011 года в журнале «Форбс».}

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

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

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

Это перевод статьи Ruby (on Rails) ecosystem bittersweet or "we like to hate PHP", написанной 30 мая 2016, т.е. совсем недавно. Я полностью согласен с её автором, и сам давно горел желанием написать что-то подобное в последнее время, но у меня не так много опыта с Ruby, поэтому моя писанина не была бы настолько объективна, как писанина человека, который этот опыт имеет, и имеет его в хорошем количестве. А тут на тебе: всё в одном месте уже собрано, и мысли прямо один в один как у меня. Грех не перевести на русский. Также, статья вообще очень хороша как небольшой набор объективного и беспристрастного анализа двух языков современной веб-разработки. В общем, далее — перевод слов автора.

многобукв; нечитал;
В этой статье я рассказываю о некоторых фактах и персональном опыте для того чтобы доказать, что PHP в данный момент живее, конкурентоспособнее, а также имеет менее связанную экосистему, чем Ruby. Я говорю о Производительности, Синтаксисе и Аспектах кодинга, Сообществе и Инструментарии разработчика.

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

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

Данная статья — попытка этот обзор написать. Хотя нет, это скорее пост ненависти и боли (может даже немного нытья). Это такой расширенный вариант поста про минусы от pistol. Я постараюсь описать большинство тех вещей, которые раздражают именно меня и моих коллег в Битриксе. Постараюсь собрать в одном посте все те минусы, которые доставляют ежедневно очень много боли. Под конец я постараюсь сделать выводы.

Кто я такой? Да в общем-то, обычный разработчик. Работаю с битриксом с ноября 2010 года (5.5 лет). Работаю только с битриксом, не сделал ни одного коммерческого проекта на других CMS, не использовал фреймворки в создании сайтов. По роду деятельности я занимаюсь в основном интернет-магазинами, их созданием, поддержкой и развитием.

Примечание переводчика: визит под кат этого поста означает большие объёмы потреблённого трафика. И это иронично, если учесть поднятую тему. Но всё сразу встаёт на свои места, если помнить, что в оригинале это было выступление в прошлом ноябре в Сиднее длиной почти в час. Чтение поста занимает куда меньше времени. В форме видеозаписи (1280×720) речь занимает два гигабайта. Пост же занимает всего лишь 12 МиБ. Рекомендуется просмотр на широких мониторах.



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

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

То, о чем я попытаюсь сейчас рассказать, выглядит как настоящая магия.

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

Итак, магия:


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

Добрый день!

В данной статье я хочу рассказать о проблеме классификации данных методом опорных векторов (Support Vector Machine, SVM). Такая классификация имеет довольно широкое применение: от распознавания образов или создания спам-фильтров до вычисления распределения горячих аллюминиевых частиц в ракетных выхлопах.

Сначала несколько слов об исходной задаче. Задача классификации состоит в определении к какому классу из, как минимум, двух изначально известных относится данный объект. Обычно таким объектом является вектор в n-мерном вещественном пространстве . Координаты вектора описывают отдельные аттрибуты объекта. Например, цвет c, заданный в модели RGB, является вектором в трехмерном пространстве: c=(red, green, blue).

Всем привет. На этой неделе в курсе по машинному обучению профессор Andrew Ng рассказал слушателям про метод главных компонент, с помощью которого можно уменьшить размерность пространства признаков ваших данных. Но к сожалению он не рассказал про метод вычисления собственных векторов и собственных чисел матрицы, просто сказал, что это сложно и посоветовал использовать матлаб/октавовскую функцию [U S V] = svd(a).

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

Доброго времени суток, читатель. Random Forest сегодня является одним из популярнейших и крайне эффективных методов решения задач машинного обучения, таких как классификация и регрессия. По эффективности он конкурирует с машинами опорных векторов, нейронными сетями и бустингом, хотя конечно не лишен своих недостатков. С виду алгоритм обучения крайне прост (в сравнении скажем с алгоритмом обучения машины опорных векторов, кому мало острых ощущений в жизни, крайне советую заняться этим на досуге). Мы же попробуем в доступной форме разобраться в основных идеях, заложенных в Random Forest (бинарное дерево решений, бутстреп аггрегирование или бэггинг, метод случайных подпространств и декорреляция) и понять почему все это вместе работает. Модель относительно своих конкурентов довольно таки молодая: началось все со статьи 1997 года в которой авторы предлагали способ построения одного дерева решений, используя метод случайных подпространств признаков при создании новых узлов дерева; затем был ряд статей, который завершился публикацией каноничной версии алгоритма в 2001 году, в котором строится ансамбль решающих деревьев на основе бутстреп агрегирования, или бэггинга. В конце будет приведен простой, совсем не шустрый, но крайне наглядный способ реализации этой модели на c#, а так же проведен ряд тестов. Кстати на фотке справа вы можете наблюдать настоящий случайный лес который произрастает у нас тут в Калининградской области на Куршской косе.

Доброго времени вам суток, уважаемое Хабрасообщество.

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

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

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

Привет. Я хочу продолжить тему реализации методов машинного обучения на c#, и в этой статье я расскажу про алгоритм обратного распространения ошибки для обучения нейронной сети прямого распространения, а также приведу его реализацию на языке C#. Особенность данной реализации в том, что реализация алгоритма абстрагирована от реализаций целевой функции (той, которую нейросеть пытается минимизировать) и функции активации нейронов. В итоге получится некий конструктор, с помощью которого можно поиграться с различными параметрами сети и алгоритма обучения, посмотреть и сравнить результат. Предполагается, что вы уже знакомы с тем, что такое искусственная нейросеть (если нет, то настоятельно рекомендую для начала изучить википедию или одну из подобных статей). Интересно? Лезем под кат.