В посте от 29 февраля мы уже рассказывали о квантовом скачке, произошедшем в области хранения данных с появлением DSSD D5, высокопроизводительного хранилища стоечного класса на flash-накопителях. Майк Шапиро, сооснователь стартапа DSSD, купленного впоследствии EMC, и вице-президент по разработке ПО EMC, рассказал о некоторых особенностях продукта, о том, зачем он нужен, а также о планах по развитию самого быстрого флэш-хранилища в индустрии.



Когда мы слушали презентацию DSSD, невольно возникал вопрос – почему этот продукт появился именно сейчас? Вы сами сказали, что разработка заняла примерно пять лет. Как возникло понимание, что продукт готов, и его пора выпускать на рынок?

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

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

Много картинок!

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



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

В прошлом посте мы писали о том, как Островок.ru привлёк инвестиции размером 1 млн долларов от лучших инвесторов всего за 6 недель, имея только идею.

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

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

На UpStartConf – секции о рынке инвестиций и стартапов в рамках РИФа-2011 основатели Островок.ру рассказывали о том, как привлечь в Рунет мировых инвесторов.

Эксперты, инвесторы и IT-предприниматели Рунета сошлись в едином мнении, что на российском интернет-рынке нет публичных кейсов стартапов, нет обучения для начинающих веб-предпринимателей, что неблаготворно влияет на рынок. В этом посте репатрианты Кирилл Махаринский и Сергей Фаге презентуют кейс по привлечению инвестиций на примере проекта Островок.ру

Startup Genome Report — это огромный отчет, основанный на анализе 3200+ стартапов со всего мира. Состоит он из огромного количества графиков, показывающих сходства и различия между успешными и неудачными стартапами.
Недавно вышло большое дополнение на 60 страниц о том, что для стартапов, которые начинаются вполне успешно, основной причиной итогового фейла является преждевременное масштабирование. То есть когда стартап начинает расширяться, не будучи к этому готовым.
Этот отчет теперь доступен на русском, почитать и скачать его можно здесь.
Первая версия отчета, также переведенная на русский, лежит тут.

Это первая версия перевода, будем благодарны за фидбеки и т.д.

Краткая выжимка признаков того, что проекту еще рано масштабироваться с точки зрения уровня развития разных направлений:

Потребитель

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

Продукт

• Создается продукт, но нет готовности решать возникающие проблемы;
• Вкладываются средства в масштабирование продукта прежде, чем продукт готов соответствовать требованиям рынка;
• Добавляются дополнительные характеристики, которые продукту «хорошо бы иметь».

Около года назад, после первого знакомства с Flurry у меня прямо вырвалось — она же рвет Google Analytics как Тузик грелку тряпку какую-то материю. И обещался написать об этом повесть. Еще до знакомства с Flurry, для своего первого приложения пришлось использовать именно гугловую аналитику, стабильную но в бета-версии. С того момента все повзрослели но я так и остался с Flurry. Пост о том, какой от нее прок и как ее готовить. А готовить ее как два пальца яйца о сковородку.

Рабочий — это источник идей, а не просто пара действующих рабочих рук.
Биант.

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

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

Обойдусь без копипастов и даже ссылок о том, что Ruby за зверь такой, ибо написано было уже сполна. В данном посте просто хочу рассказать о пути изучения Ruby (и, впоследствии фреймворка Ruby on Rails) человека далекого от программирования.

1. Любопытство

«Насколько далекого?», спросите вы, а я отвечу — «Чуть менее, чем полностью», так как в десятом классе в школе у меня были уроки программирования, парочка из которых были уделены Паскалю. Признаюсь, впоследствии о html узнал, и даже мог в Dreamweaver-e сверстать страничку или поставить готовый движок, да по инструкции налепить плагинов, но не более.
Хотя компьютеры мне нравились, пошел я учиться на экономиста* — бакалавриат, магистратура по бух. учету и аудиту, аспирантура по финансам, работа в банке, преподавание, страхование. Но не жилось мне спокойно в финансах, — финансовый калькулятор удовлетворял необходимости решения тривиальных задач, но не удовлетворял мой мозг. А ему хотелось посчитать не только будущую и приведенную стоимость актива, но и создать массив данных из исторических стоимостей этого актива за n лет, высчитать среднюю доходность, дисперсию и, в конце-концов построить красивый график!

В начале, как обычно, было слово. В нашем случае – идея. Идея сделать сервис, которого давно не хватало нам самим. Расхожая фраза о том, что лучший бизнес – тот, клиентом которого хочется стать самому, оказалась как нельзя кстати.

Прочитав много литературы по истории бизнеса и наблюдая рост популярности Интернет-торговли, автору этих строк хотелось реализовать свои знания на практике. Искали подходящую тему для проекта. Необходимыми условиями были:

1) Вложение не более $10 000
2) Прибыль не менее $1 000 в месяц
3) Минимальная рутина

По первым двум пунктам все понятно. А вот по третьему пункту поясню. К тому моменту я уже работал в собственной компании (сфера финансов). Это был 2009 год. Последствия кризиса еще сильно влияли на основной бизнес и работы было непочатый край. Много времени отвлекать на сторонний бизнес автор не мог.
Подходящий случай подвернулся в октябре 2009 года.

Сегодня мы предоставим вашему вниманию перевод поста Стива Клабника (Steve Klabnik), известного разработчика, приверженца Ruby, одного из победителей Ruby Hero Award этого года. Что это за награда? Она присуждается победителями прошлого года тем участникам сообщества, которые наиболее проявили себя: создали значимый обучающий контент, разработали плагины и гемы, участвовали в проектах с открытым кодом. Такая награда была создана для того, чтобы отметить наиболее проявивших себя людей и дать им признание, которое они заслуживают.
Пообщаться со Стивом можно будет на конференции в Киеве RubyC 5-6 ноября этого года.

Я часто говорю людям, что учил Ruby через Rails. Это один из худших способов, но к тому времени я уже выучил столько языков программирования, что это не мешало мне. Тем не менее, это дало мне слегка искаженное ощущение того, насколько тщательно проектировать классы, необходимые для Rails приложений. К счастью, я пристрастно просматриваю код, написанный другими, и заметил, что есть одна важная вещь, которая встречается в разработках у многих уважаемых мною людей.

Мне кажется, эти люди также считают эту вещь уникальной. Это не когда люди, не умеющие писать хороший код, стараются, но все равно получается плохо. Это как флаг, сигнал. Теперь, когда я вижу, как кто-то внедряет эту вещь, я сразу думаю: «он шарит». Возможно, я слишком сильно доверяю своему чувству, но эта продвинутая техника разработки предлагает множество взаимосвязанных преимуществ вашим Rails приложениям, легко применима и ускоряет тестирование на порядок или больше. К сожалению, для многих начинающих Rails разработчиков это неочевидно, но я хотел бы, чтобы вы писали код лучше и вот я здесь, чтобы, с вашего позволения, «раскрыть секрет» и поделиться этой мощной техникой с вами.

Компания Startup Genome опубликовала приложение к майскому аналитическому отчёту по стартапам. Теперь собрана информация уже по 3200+ компаниям и подробно рассматривается главная причина, по которой стартапы разваливаются.

Изучив опыт тысяч стартапов, Startup Genome делает вывод: 70% неудач объясняются преждевременным масштабированием.

Где-то 3 месяца назад в нашей фирме поднялся вопрос о регистрации обращений пользователей в IT отдел. Мне было поручено просканить интернет на предмет системы учета заявок, такого себе хелпдеска. Требования были предъявлены следующие:
1. Бесплатность (да-да, платить за эту систему отказались).
2. Возможность сбора статистики (для больших боссов).
3. Сигнал на почту (не только админам, но и пользователям, а так же всем заинтересованным именно в этой заявке лицам).
4. FAQ и база знаний.
Сказано — сделано. Так как все эти системы для меня были в новинку, то по совету на каком то из форумов я выбрала GLPI. Тем более, что эта система обещала облегчить процесс инвентаризации, что является довольно неплохим бонусом!

Доброго времени суток, уважаемые читатели.

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

Я думаю, что для тех, кто работал в обычной российской компании численностью менее 20-30, не секрет насколько руководство зажимает деньги на развитие IT. Так было и в компании X, где я работал.