Игорь Артамонов

Погоняв Google App Engine пару месяцев расскажу о впечатлениях от него.
Платформа несомненно интересная, и будет очень полезна startup’ам, т.к. позволяет сосредоточится на решении своих конкретных задач, отдав все что не является конкурентым преимущество на откуп платформе и её сервисам.

К сожалению прям вот взять любой сайт и запустить его на GAE не получится, нужно делать именно под него, на Python или JVM, и нужно хорошо понимать как это работает. Я смотрел лишь связку Python + Django. Многие преимущества Django тут отсутствуют (например знаменитая админка django), но тем не менее результат получается очень быстро и вполне качественно. Для JVM есть многообещающий Gaelyk, ну и куча прочих framework’ов.
Читать далее »»

Пообщался на днях, в очередной раз, с человеком пишушим свой поисковик, убийцу яндекса и гугла вместе взятых Я попытался донести что рынок поиска, в текущем виде, занят, по крайней мере от посягательства со стороны небольших команд. Есть Гугл как основной гигант, есть куча игроков рядом с ним поменьше, и есть несколько тысяч совсем незаметных поисковиков, вертикальных, узкоспециализированных, экспериментальных и пр. Даже мелочь, конечно, имеет своих посетителей, но все равно тут делать нечего, лишь гиганты могут методично вычищать свои алгоритмы, нанося небольшие, малозаметные штрихи в общей картины. Время больших мазков давно прошли. И занять тут значительную долю не получится, даже вкладывая миллиарды в маркетинг, в Bing я слабо верю. Это никому не нужно, даже пользователям, как ни странно это звучит.

Единственный заметный результат дает «структуризация веба», а точнее структурированный и полноценный ответ на его основе. В идеале как у Вольфрама. Вольфраму более менее удалось лишь потому что они выбрали очень специфичную, узкую, и изначально структурируюмую область, в которой, к тому же, они давно сидели. Конечно же продвижения есть и остальных, и у Гугла, и у Яндекса, и особенно мне нравится как это получается у Нигмы. При этом охватить сразу всё, дать ответ на любой вопрос, им слишком трудоемко, на приборах почти не заметно, а ROI совсем плохой.
Читать далее »»

Запустил небольшой сервис для студентов, как раз к сессии. Это сервис совместной подготовки к экзамену: www.konspektov.net

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

Идея простая, и плавает на поверхности. Все равно все так или иначе это делают, кто-то пересылкой по email, кто-то Google Docs использует. А это специализированный инструмент для данной задачи.

Запускать решил сразу, сходу, как только получился прототип. Решил поэксперементировать, попробовать на практике что такое «выкатывать как можно раньше». Запостил сегодня ссылку на хабре, в результате через 20 минут топик вышел на главную, рейтинг держится на уровне +40, ~80 комментариев, пара тысяч уников на сайте, и куча советов, идей и пр. Ни смотря на такую сырость сервиса, было мало эмоциональной критики, все общение было по делу и судя по всему это очень востребованный сервис, можно доделывать. Так что показывать такую альфа-версию вовсе не страшно, и даже очень полезно. Буду иметь ввиду

Кто нибудь занимается datamining, textmining, ir и прочими делами с большими массивами данных? Вот запустил небольшой сервис: datasetpublisher.com – торрент трекер для коллекций данных. Т.е. чтобы не качать очередные 5G дампа википедии со скоростью 70Kb/s (докачается как раз к моменту когда выложат новый дамп), а скачать с нормальной скоростью через торрент.

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

Проект запущен на Google App Engine, что собственно и послужило причиной его появления. Уж очень я в последнее время заинтересовался этой платформой, и решил поэксперементировать. А так как я очень не люблю что-то делать «в корзину», и считаю что подобные эксперименты, помимо исследовательской цели, должны принести конкретный применимый сейчас результат. И вспомнил разговор с Иваном Бегтиным, незадолго до этого, о том что неплохо бы иметь подобный ресурс. Теперь он есть. И с GAE разобрался, на него еще посмотрю как вести себя будет, и напишу свое мнение.

В предыдущей заметке про психологические роли разработчика я сказал что они явно конфликтуют друг с другом, и я утверждал что это конфликт очень важен. Т.е. я вообще сторонник того что конфликт это нормально, он нужен, если его видеть, правильно понимать и направлять на благо компании и его участников. А если нет конфликта, и два человека полностью согласны во всем друг с другом, имеют один взгляд во всем, то зачем нужен второй человек?
Читать далее »»

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

Он выделил 4 роли: Producer – Administrator – Enterpreneur – Integrator – сокращенно PAEI. Адизес описал все в общем случае, мне же это интересно на примере команды разработки ПО. Только я позволю себе перевести названия ролей не дословно.
Читать далее »»

Google: Designs, Lessons and Advice from Building Large Distributed Systems:

И еще видео (которое фиг просмотришь нормально) примерно на ту же тему от Facebook:
High Performance at Massive Scale – Lessons learned at Facebook (может кто-то сможет перезалить его на YouTube или Google Video?)

Нашел интересный прототип фреймворка для распределенных вычислений: Swarm-DPL

Основная идея в том что код выполняется как можно ближе к данным, и даже больше, он постоянно мигрирует между разными машинами, старясь быть ближе к ним, без остановки основного вычислительного алгоритма. В общем это continuations с переносом состояния между нодами. Это в пику подходу map-reduce когда у нас именно данные гоняются между нодами. Код все таки меньше места занимает, должно быть быстрее, это не гигабайты данных по сети гонять.

Рекомендую посмотреть презентацию:

Swarm: Distributed Computation in the Cloud from Ian Clarke on Vimeo.

Реализовано на Scala, хотя думаю что никто не мешает реализовать идею на другом языке, и тем более уж под JVM. Автор, правда, утверждает обратное, но причина в том что в Scala все уже есть для этого, уже сейчас, и для прототипа как раз подходит. Ну и насколько я понимаю подобную оптимизацию можно реализовать в GridGain и сейчас, указав ноды для MR, но тут идея более интересная.

Наверное все в курсе произошедшей на этой недели покупки SpringSource компанией VMWare. Меня, например, это сильно удивило, совсем не ожидал. Судя по прессрелизу все ради того чтобы обосноваться в нише cloud computing. Ну в общем да, на уровне инфраструктуры виртуализации у VMWare все хорошо, даже очень, а вот в остальном видимо решили докупиться (к тому же виртуализацией как таковой сейчас занялись очень многие, надо идти дальше, предлагать платформу).

И я их наверное начинаю понимать, cloud computing это довольно специфичная область. Читать далее »»

Вот кстати замечательный доклад по поводу оценки сроков от Максима Дорофеева: Курс естествознания для менеджера проекта, рекомендую потратить время и посмотреть/послушать.

Ну и, бонусом к оценке сроков, идут интересные слайды про «Персики и Лимоны», как отличное дополнение к принципу Питера