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

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

Следующий момент который надо уяснить – для кого делаются такие выступления. Конечно, если говорить о стартап-соревнованиях, то они делаются для инвесторов, но кроме того они могут подготавливаться для банкиров, потенциальных спонсоров, руководства, сотрудников, клиентов, партнёров. В общем, для всех, кому необходимо что-то продать.

Третье, следует понимать, что существует несколько видов питч-выступлений:

1) Elevator pitch, длительность которого 1 минута. Основная цель – заинтересовать инвестора, чтоб получить приглашение на вторую встречу. За данную минуту необходимо успеть кратко сказать о существующей проблеме; о решении, которое вы предлагаете; и рассказать какие существуют перспективы по монетаризации данного проекта.

2) Idea pitch, длительность которого до 3 минут. Данный вид питчинга наиболее часто практикуется в стартап конкурсах. Он состоит из следующих элементов:

Для разработки приложений фреймворка Meteor существует некоторое число приемов и средств, предназначенных для обеспечения безопасности. В первой части мы поговорим о более известных вещах — скрытии серверной части кода, пакетах autopublish / insecure, скрытии полей коллекций при публикации и встроенной системе учетных записей, заглянув внутрь коллекции Meteor.users. Во второй — про loginToken, выдаваемый клиенту, правила allow/deny при модификации базы данных клиентом, доверенном и недоверенном коде, серверных методах, HTTPS, пакете force-ssl и пакете browser-policy (Content Security Policy и X-Frame-Options), встроенном механизме валидации данных (функция check() и пакет audit-arguments-check).

Введение

На хабре уже несколько раз упоминали о проекте Meteor, основанном в 2011 году семерыми энтузиастами web-технологий из Сан-Франциско. По сути Meteor является просто надстройкой над node.js, который сам ещё даже не дошёл до релизной версии. Тем не менее проект собрал более семи тысяч подписчиков на github и получил 11 миллионов долларов инвестиций.
С чего такая популярность? Дело в заявлении авторов о том, что они хотят кардинально переосмыслить способ написания современных web-приложений в сторону его упрощения. Не секрет, что написание кода на чистом node.js довольно сильно выворачивает мозг и вынуждает использовать различные костыли в виде control flow средств. На Meteor, говорят авторы, писать крутые приложения сможет даже гуманитарий.
Ну что же, проверим. Имеется: 1 гуманитарий-социолог, закрывший сессию и желающий после Парсонса и Зиммеля перейти на что-нибудь полегче, компьютер с Ubuntu 12.10 и установленный node.js (не спрашивайте, как он оказался у социолога).

Вдохновимся обещаниями разработчиков, прекрасной девушкой-членом команды и начнём.

От переводчика: MeteorJS — открытый (MIT) фулстек JavaScript фреймворк (и клиент и сервер). Текущая версия 0.6.6.3 — в начале 2014 планируется выход версии 1.0. Публикации на хабре: 1, 2, 3.

В статье обзор сетевой архитектуры Метеор-приложения.

Метеор как сервер, Метеор как клиент

Приложение Метеор, с точки зрения браузеров, прокси-серверов, маршрутизаторов и других сетевых компонентов, является, по сути, обычным веб-приложением. Хотя, на самом деле, Метеор-приложение состоит из двух главных частей: часть, которая работает внутри браузера и часть, которая работает как сервер. Эти две части настроены таким образом, чтобы взаимодействовать друг с другом способом, характерным для многих современных веб-приложений (таких, как Gmail или Trello)


Метеор позволяет разработчикам создавать приложения не заботясь о сложностях клиент-серверного взаимодействия.

Автор картинки: Donovan Shortey, использовано по лицензии Creative Commons.

Познавательная книжка Discover Meteor теперь переведена усилиями сообщества на русский язык и находится в свободном доступе. Английская версия по-прежнему требует подписки и стоит (разумных) денег.

В начале марта авторы оригинальной книжки Sacha Greif и Tom Coleman бросили клич, приглашая любителей фреймворка MeteorJS перевести ее на все языки мира. Локализированные версии книжки выкладывались бы под свободной лицензией Creative Commons, свободно доступные для всех желающих быстро познать мир Meteor. В настоящий момент существуют переводы на 22 языка мира, в разной степени готовности. Проект доступен на GitHub, и если кто-то заметил опечатку, или желает как-то дополнить перевод — добро пожаловать в команду.

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

Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в Mail.Ru над Next-Gen MMORPG Skyforge. Вы могли читать мою статью про архитектуру баз данных в онлайн-играх. Сегодня я буду раскрывать секреты, касающиеся устройства сервера Skyforge. Постараюсь рассказать максимально подробно, с примерами, а также объясню, почему было принято то или иное архитектурное решение. По нашему серверу без преувеличения можно написать целую книгу, поэтому для того, чтобы уложиться в статью, мне придется пройтись только по основным моментам.

Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.

Одним из самых главных изменений является поведение команды git push. Теперь по умолчанию (если не указана ветка) push будет осуществлен только в текущую ветку. Git 1.* по умолчанию делал push во все ветки, которые были изменены локально. Конечно же можно вернуться к прежнему поведению, для этого служит опция push.default.

Поведение Git 1.*:

git config --global push.default matching

Новое поведение по умолчанию в Git 2.0:

git config --global push.default simple

Другие изменения:

Лучше день потерять, но потом за пять минут долететь (с)

Привет коллеги.
Хочу поделиться с вами соображениями о том, чем отличаются фреймворки Hive и Pig, входящие в экосистему Hadoop. По сути, это два очень похожих продукта, цель у которых одна — взять на себя всю техническую реализацию MapReduce, предоставив взамен возможность описывать процесс обработки данных на более абстрактном уровне. В этой статье мы увидим как выглядят выборки в этих двух системах, и попытаемся понять, в каких случаях надо использовать то или иное решение.

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

8 апреля в официальном блоге Ruby on Rails появилось сообщение об официальном выходе Rails 4.1. Весь функционал уместился в 5200 коммитов.

На хабре уже был обзор бета версии. Также можно почитать Release notes и A Guide for Upgrading Ruby on Rails.

В статье я бы хотел остановиться на некоторых тонкостях и деталях того, что под капотом.

Привет, Хабр!

В прошлый раз мы насладились звуком включения Sony PlayStation, геймплеем Atari Jaguar и рекламой Nintendo 64. В этот раз обсудим шестое поколение игровых консолей.

Сегодня в меню: Sega Dreamcast, Sony PlayStation 2, Nintendo GameCube и Microsoft Xbox.

Sega Dreamcast

Эпоха 128-разрядных игровых приставок началась в ноябре 1998 года, когда в продаже на японском рынке появилась Sega Dreamcast. В США приставка появилась только в сентябре 1999 года по цене 199 долларов. В рекламе обыгрывалась тема «девяток»: 9.09.99.

Над приставкой работали сразу две команды — в США и в Японии. В итоге остановились на японском варианте с процессором Hitachi SH4 и графическим процессором PowerVR от VideoLogic. Старт продаж был столь успешным, что компания попросту не справлялась с запросами покупателей: производство отставало. Всего в первые сутки продали 225 132 приставки.

Госвласть в России уже несколько месяцев самозабвенно придумывает, как бы понадежнее обнять любимый кластер — IT. Тут и ограничения платежей, и блокировки без суда, и давно хорошо знакомые выемки серверов. Новый тренд — регистрация. Таких законопроектов существует аж 2, один уже принят в первом чтении Госдумой, второй болтается между Правительством и СФ.

И вот — встречайте — третий!

Это — сиквел моей сногсшибательной первой статьи.

Готов поспорить что каждый веб разработчик сталкивался с фейсбук коннектом или вконтакте логином или аутенфикацией через твиттер. Все это по сути построено на основе OAuth1/2.

Мое мнение заключается в том что мы все ступили не на ту дорожку. OAuth это дорожка в ад (к слову, Эран Хаммер сейчас работает над заменой oauth — oz).

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

1. Вступление

Всем привет! Не так давно мы стартовали ОБТ нашего нового online-проекта Metal War Online. Со временем мы захотели выйти на глобальный рынок посредством Steam и, как большинство коллег, осуществляем эту затею через сервис Greenlight. Нашему опыту прохождения аппрува и будет посвящен материал.

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

Если вы являетесь rails-разработчиком, то вы наверняка слышали про Unicorn, http-сервер, способный одновременно обрабатывать множество запросов.

Для обеспечения параллельности Unicorn использует создание множества процессов. Т.к. созданные (форкнутые) процессы являются копиями друг друга, это значит, что rails-приложение должно быть потокобезопасным.

Это здорово, т.к. нам тяжело быть уверенными, что наш код является потокобезопасным. Если мы не можем быть уверены в этом, то ни о параллельных веб-серверах, таких как Puma, ни даже об альтернативных реализациях Ruby, реализующих параллелизм, таких как JRuby и Rubinius, не может быть и речи.

Поэтому Unicorn предоставляет нашим rails-приложениям параллельность даже если они не потокобезопасны. Однако, это требует определенной платы. Rails-приложения, запускаемые на Unicorn’е требуют гораздо больше памяти. Не обращая никакого внимания на потребление памяти вашим приложением, вы можете в итоге обнаружить, что ваш облачный сервер перегружен.

В этой статье мы рассмотрим несколько способов использования параллельности Unicorn'а, при этом контролируя количество потребляемой памяти.

Данным постом хотелось бы начать цикл статей о том, как мы адаптировали под свои нужды трекер задач «Redmine».

Около 2-х лет назад мне пришлось достаточно сильно изменить профиль своей деятельности, и от системного администрирования уйти в разработку на фреймворке «Ruby on Rails». Нужно было адаптировать «Redmine» под нужды достаточно большого IT-отдела, а потом и под нужды компании в целом. Тогда, я столкнулся, с относительной не простотой установки «Redmine». И комплексной статьи для новичков очень не хватало!

Есть несколько способов установки ROR-приложения, которым является «Redmine». В данной статье речь пойдет об установки на web-сервер «Apache», с использованием «Passenger» и «RVM». В качестве сервера баз данных, мы до сих пор используем «MySQL» (вернее MariaDB), хотя и подумываем о переезде на «PostgreSQL».

Об авторе: выпускник НИУ-ВШЭ, в настоящее время работает над проектом по Semantic Web в Институте им. Лейбница и учится в университете Мангейма, Германия по последипломной стипендии DAAD

Данная статья – это своеобразный FAQ (пригоден и для «неайтишников»), который содержит ответы на основные вопросы по поводу поступления за рубеж и получения стипендии, предполагающий сильное желание, но ограниченное количество финансовых ресурсов у студента. Основная цель – правильно направить способных заинтересованных людей. Представленная информация касается, прежде всего, магистратуры (MA/MSc), однако многое, с некоторыми оговорками, также применимо и для аспирантуры (PhD). Итак:

Rails предоставляют нам 4 различных способа загрузки ассоциаций: preload, eager_load, includes и joins. Рассмотрим каждый из них:

Preload

Этот метод загружает ассоциации в отдельном запросе:

User.preload(:posts).to_a

# =>
SELECT "users".* FROM "users"
SELECT "posts".* FROM "posts"  WHERE "posts"."user_id" IN (1)

Т.к. preload всегда создает два отдельных запроса, то мы не можем использовать таблицу posts в условии выборки:

User.preload(:posts).where("posts.desc='ruby is awesome'")

# =>
SQLite3::SQLException: no such column: posts.desc:
SELECT "users".* FROM "users"  WHERE (posts.desc='ruby is awesome')

А таблицу users – можем:

User.preload(:posts).where("users.name='Neeraj'")

# =>
SELECT "users".* FROM "users"  WHERE (users.name='Neeraj')
SELECT "posts".* FROM "posts"  WHERE "posts"."user_id" IN (3)

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

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

• Убережём пользователя от ошибок (при вводе неверного индекса он сразу заметит, что город-то не его), что, в случае доставки письма (а то и посылки), может здорово её ускорить (пока её по неверному индексу зашлют, да пока разберутся, что не туда заслали, да отправят туда — пользователь вам всю плешь проест)
• пользователю будет приятно, что о нём заботятся :-)

Дело за малым: нам нужна база почтовых индексов.

И она есть! Всамделишняя, электронная и, главное, официальная база индексов от Почты России.