Мы в Alconost предоставляем услуги создания и ведения контекстной рекламы и, по долгу службы, иногда занимаемся разработкой посадочных страниц (landing pages). Мы были очень рады найти и перевести статью, в которой автор изложил все требования, которым такая страница должна соответствовать. Но есть в этой статье и большой минус. Пунктов аж 50, каждый можно отметить в чеклисте, но после доступен лишь результат в баллах, которым можно разве что похвастаться перед друзьями.

Мы против таких способов анализа информации. Потому каждый желающий может скачать подготовленную нами гуглотаблицу, ответить на вопросы “Да” или ”Нет”, отфильтровать ответы и получить результат и план действий.

Те, кому в гуглотаблицу не хочется, просим под кат. Там перевод.

Проверьте свой проект: вы летите или думаете, что летите?

Ниже вопросы, которые стоит задавать себе на старте проекта и время от времени на его протяжении.

Контрольные вопросы на старте проекта:

1. Что конкретно нужно сделать на текущем этапе? В целом? Есть ли чётко определённые цели каждого этапа? Как вы определите, что цели достигнуты? Соответствует ли текущий статус заявленным планам и целям или их необходимо корректировать?
2. Реалистичны ли эти цели?
3. Что случится, если цели не будут достигнуты в срок? Каков план действий?
4. Насколько этот проект значим? Например, зависит ли от него место вашей компании на рынке?
5. Какую выгоду вам, обществу и инвесторам принесёт проект?
6. Достаточно ли хорошо спланирован проект? Все ли в вашей команде понимают пункты плана одинаково?
7. Нужны ли внешние эксперты, например, юристы?
8. Есть ли у команды опыт работы вместе? Кто будет координировать команду? Важно ли для проекта работать именно вместе — или возможен труд одиночек? Отвечает ли каждый член команды за работу всех остальных?
9. Можно ли сократить размер команды? Если нет, то почему? Если да, то почему это не сделано?
10. Как вы будете компенсировать форс-мажоры с персоналом, например, что случится, если ваш ведущий разработчик сломает руку?

Недавно вышла статья Пола Грэма о поиске идеи для стартапа. Грем — сам по себе культовая личность Кремниевой долины и уже только поэтому достоин внимания. Но на мой взгляд, эта статья одна из лучших в своем роде. Да, о Customer Development и Lean Startup сейчас не пишет разве что ленивый, но она отличается глубокой внутренней философией Грема и обобщает его богатый опыт в качестве основателя YCombinator, общающегося с тысячами стартаперов в год.
Статья очень длинная, поэтому я взял на себя смелость разбить ее на 5 частей, дабы никого не утомить. Поехали:

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

13 июня 1944 года, через неделю после вторжения союзников в Нормандию, громкий жужжащий звук прогремел в небе избитого боями Лондона. Источником звука было недавно разработанное немецкое орудие войны: воздушная бомба V-1. Будучи предшественником крылатых ракет, V-1 была самоходной бомбой, управляемой с помощью гироскопов, питалась она от простого пульсирующего воздушно-реактивного двигателя, который поглощал воздух и воспламенял топливо 50 раз в секунду. Такая высокая частота пульсации давала бомбе характерный звук, зарабатывая ей прозвище «жужжащая бомба» (в оригинале – «buzz bomb» – прим. перев.).

Доброе время суток, уважаемое хабрасообщество!
Неделю назад я наконец-то дождался свою Малинку. Этот пост о том, как можно набить шишки в такой простой задаче как работа с датчиками температуры.
Кому интересно — добро пожаловать под кат.

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

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

 

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

— Именем Князя Питерского, давайте сюда декларацию. Что везем? Откуда?
— Из Новосибирска. 256 мегабайт сертифицированных данных для Интернета Его Высокопревосходительства. Научные, метеорологические, новости, деловая и частная корреспонденция, — доложила я, зная, что таможня шутить не любит.
— Открывайте, посмотрим.
— Что, все 256 мегабайт смотреть будете?

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

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

Ключевые слова async и await, введённые в C# 5.0, значительно упрощают асинхронное программирование. Они также скрывают за собой некоторые сложности, которые, если вы потеряете бдительность, могут добавить проблем в ваш код. Описанные ниже практики пригодятся вам, если вы создаёте асинхронный код для .NET приложений.

Вебсокеты — это прогрессивный стандарт полнодуплексной (двусторонней) связи с сервером по TCP-соединению, совместимый с HTTP. Он позволяет организовывать живой обмен сообщениями между браузером и веб-сервером в реальном времени, причем совершенно иным способом, нежели привычная схема «запрос URL — ответ». Когда два года назад я присматривался к этому стандарту, он был еще в зачаточном состоянии. Существовал лишь неутвержденный набросок черновика и экспериментальная поддержка некоторыми браузерами и веб-серверами, причем в Файрфоксе он был по умолчанию отключен из-за проблем с безопасностью. Однако теперь ситуация изменилась. Стандарт приобрел несколько ревизий (в том числе без обратной совместимости), получил статус RFC (6455) и избавился от детских болезней. Во всех современных браузерах, включая IE10, заявлена поддержка одной из версий протокола, и есть вполне готовые к промышленному использованию веб-серверы.

Я решил, что настало время попробовать это на живом проекте. И теперь делюсь, что из этого вышло.

Ранней осенью этого года мы с коллегами из CMS Magazine провели опрос, в котором приняли участие и поделились своим опытом и мнением всего более 500 веб-студий и агентств, за что им огромное спасибо.
Часть результатов мы публикуем здесь, надеясь на то, что многие из вас заинтересуются этими данными и оставят свои комментарии или будут использовать их по необходимости в докладах/на встречах и так далее.
И да, внимание: под катом много картинок!

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

Я работаю в Почте Mail.Ru, и моей прямой обязанностью является работа с JavaScript во всех его проявлениях. Прикрепление файлов к письму — одна из основных функций любой почты. Мы тут не исключение: у нас уже был Flash-загрузчик, который вполне исправно работал и долгое время нас устраивал. Однако у него был ряд недостатков. Вся верстка, графика, бизнес-логика, и даже локализация были зашиты в нем, в результате чего решение было громоздким, а внести правки мог только Flash-разработчик. В какой-то момент мы поняли, что нам необходим новый механизм. О том, как его создать, пойдет речь в этой статье.

Мне очень нравится JavaScript и я считаю его мощным и удобным. Но для большинства начинающих JS-программистов, много проблем создаёт недопонимание аспектов языка. Часто конструкции языка ведут себя «нелогично». В данной статье я хочу привести примеры «граблей», на которые я наступил; объяснить поведение языка и дать пару советов.

Существует множество компаний, которые продают товары клиентам или оказывают какие-то услуги. Часто продавцы интуитивно принимают решения, какой именно товар из всей существующей линейки лучше подходит клиенту. Также интуитивно определяется, какой массив клиентов более интересен для компании, а для каких клиентов продажа и дальнейшее обслуживание будут слишком затратные и невыгодные.
Для технологичного понимания всех этих вопросов хорошо подходит анализ информации с помощью технологии Data mining. Автоматизируя процесс сегментации клиентов с помощью кластеризации Data mining, компания может найти ответы на множество вопросов.
Рассмотрим вариант, когда компания занимается продажей товаров или услуг и дальнейшим послепродажным обслуживанием. Соответственно у компании есть потенциальные клиенты, которым осуществляются продажи. Также есть клиенты, которые обслуживаются или были ранее на обслуживании, т.е. которым ранее уже продавали. Для простоты будем их называть обслуживаемыми клиентами.
Кратко опишу цель и идею. Для анализа необходимо взять несколько показателей (15-20), которые есть у потенциальных и обслуживаемых клиентов одновременно. Также надо выбрать 2-3 показателя, которые есть только у обслуживаемых клиентов – это целевые показатели. Провести анализ кластеризации Data mining на массиве обслуживаемых клиентов. На выходе получим несколько кластеров со своими характеристиками. Далее кластеры группируем в сегменты по целевым показателям и даем какие-то понятные для маркетологов определения. Полученную модель анализируем, и полученные кластеры проецируем на потенциальных клиентов. На выходе получаем просегментированных потенциальных клиентов. На основании полученных сегментов можно выстроить стратегию и методологию продаж для каждого сегмента клиентов.
Рассмотрим подробнее данную методику и последовательность шагов для достижения результата.

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

Да, C++ был почти идеальным языком в этом плане. Но времена меняются, старые технологии уходят и на их место приходят новые более продуктивные и удобные. Так наша команда перешла на .NET. Но в обмен на простоту разработки и удобство отладки, мы в придачу получили в довесок и простоту декомпиляции нашего ПО. Теперь хакер мог не просто обойти лицензионные ограничения, но и получить почти полный исходник нашей программы просто скормив ее рефлектору.
Разумеется, в качестве решения этой проблемы на рынке было представлено множество различных обфускаторов. Но, как ни странно, большинство из них разочаровывали меня сразу с двух сторон: и ценовой политикой (даже минимальная лицензия некоторых превосходила стоимость нашего ПО в несколько раз), и «интеллектуальностью» алгоритма. Так, после некоторых обфускаторов, умудрялись падать даже простые WinForms приложения. Что же касалось WPF, то без долгого-долгого черного шаманства над эксклудами, запустить среднего размера программу не представлялось возможным в принципе.

Так сформировалось понимание проблемы и четкое желание создать свой продукт, сводящий озвученные выше проблемы к минимуму. И появился SaaS обфускатор и протектор .NET кода AppFuscator.com

От переводчика. Занимаясь созданием и внедрением системы электронного архива, мы не раз сталкивались с ситуациями, когда организации вводят документы в систему без разбора, не уделяя должного внимания экспертизе их ценности. Об этом уже писали. В обсуждениях наших предыдущих публикаций по данному вопросу большинство участников отстаивали следующий взгляд: сохранять можно всю поступающую информацию, она в любой момент может пригодиться. Насколько обоснован такой подход в масштабах крупной организации. Что дешевле и эффективнее: сохранять все, что возможно сохранить — или же грамотно управлять информацией, своевременно удаляя все ненужное? Любопытную статью на эту тему мы нашли в блоге Джорджа Парападакиса, ECM-специалиста из компании IBM. Ее перевод мы и предлагаем вниманию наших читателей.

Время от времени в прессе всплывают всевозможные интересные факты про деятельность различных компаний. К примеру, на Хабре приводили показания Айва Джонатана, касательно дизайна ранних версий яблочных продуктов. Я решил, что было бы интересно рассказать, что это за показания, почему их приходится давать, как устроен процесс и в каком случае вам, возможно, придется пройти через это непростое испытание.

Материал этой статьи написан на основе собственного опыта. Если ваша деятельность как-то связана с американским рынком, то рано или поздно и вам (или вашим коллегам) предстоит получить этот опыт, но об этом поговорим в конце статьи.

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

Интро

В XAML (SilverLight /Wpf /Metro) конвертеры используются для самых различных целей: приведение типов, форматирование строк, калькуляция скалярного значения сложного объекта. В рамках проекта мы можем создать очень много классов-конвертеров, решающих смежные задачи (вычисление состояния заказа и конвертация его в Visibility, конвертация состояния заказа в Cursor, конвертация булевого значения в Visibility/Invisibility и т.д.). Нетривиальная ситуация: мы написали конвертер для необычно сложного форматирования TimeSpan, и теперь требуется форматировать Duration таким же образом – необходимо писать аналогичный конвертер, но уже с предварительной распаковкой TimeSpan из Duration. Вариантов преобразования строк может быть множество, и для всех преобразований потребуется такое же множество конвертеров.
Естественно, стараясь обобщить код, мы разбиваем конвертацию на более мелкие процедуры, и, как следствие, у нас встречаются классы-конвертеры, состоящие из двух строчек кода, используемые только один раз.
Многие не знают, что для упрощения ситуации и уменьшения количества строчек кода, возможно комбинирование преобразований не в классах конвертеров, но в XAML разметке, путем создания цепочек конвертеров. Для этого необходимо написать свой абстрактный конвертер, от которого мы будем наследовать все наши преобразования.

ВКонтакте проводит конкурс на создание мессенджера для Windows Phone на базе существующего API.
Дата начала конкурса – 1 августа 2012 года, дата окончания приема работ – 15 сентября 2012 года (21:00).
Призовой фонд – 2 000 000 рублей.

Группа конкурса: http://vk.com/wp_contest

Условия конкурса (http://vk.com/page-41437534_43978998):
Задание
Мы нарисовали все основные экраны и элементы интерфейса для создания мессенджера для смартфонов на базе Windows Phone с использованием платформы ВКонтакте. Полное описание функциональности доступно на отдельной странице.

Ваша задача