По данным, любезно предоставленным аналитическим порталом CMS Magazine, «на радарах» видно 286 живых русскоязычных веб-студий размером 1—3 человека, 626 — размером 4—7 человек, и 556 — размером 8—15 человек. «Живые» — это те, кто опубликовал на портале хотя бы одну работу в 2012—2013 годах.

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

Последние годы рынок всё чаще говорит о необходимости позиционирования, маркетинга и PR для веб-студий, причём если раньше это относилось к Top-10 компаний, сегодня об этих чуждых интернет-специалистам материях приходится задумываться той самой тысяче с численностью сотрудников 4—15. К счастью, и на Хабре появляются хорошие статьи на эту тему. Мы хотим дать взгляд на проблему позиционирования ещё с одной стороны.

Я собираюсь переучить на Java-программистов миллион человек.
Я собрал команду и сделал обучающий сервис, которым могу гордиться.
Рад сообщить, что теперь стать программистом легко, независимо от образования и опыта.

В жизни даже самого «махрового» IT-шника порой наступает момент, когда нужно не только вылезти из своей берлоги на улицу, но целиком перенести себя на новое место жительства. Обычный человек в таких случаях вооружается Интернетом и прочёсывает сайты недвижимости в поисках подходящих вариантов, которые отмечаются на карте, выписываются или распечатываются, а затем планомерно прозваниваются. Если наступает конец цикла, а задача ещё не выполнена — goto line 1… А на каком-то этапе человеку это надоедает и он идёт в агенство.

Вот и в моей жизни пришло время для переезда, но проведя несколько дней за такой рутинной деятельностью я вспомнил, что незря ношу бороду есть такой чудесный сервис, как Яндекс.Карты, и у них есть не менее чудесное API. Посидев одно утро и скомбинировав всё с простейшим граббером на PHP и XPath я получил такую вот красочную карту, где разными маркерами можно отмечать объекты (квартиры) по любому из критериев, или просто одним взглядом оценить, какие из них ближе к желаемому месту дислокации (в моём случае это было метро):

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

Звонков было много, за следующую неделю я посетил 17 собеседований, по 3-4 в день, в четверг я уже перестал соглашаться на собеседования, а звонки все шли и шли.

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

Когда-то я* говорил, что без идеального задокументированного кода с многоуровневой плагинной архитектурой заказчик будет мучиться в конвульсиях каждый раз, когда его пальцы будут соприкасаться с клавиатурой. Теперь я заказчик и понимаю, что мне нафиг не нужен идеальный код, депенденси инджекшены и два синьора по цене одного. Главное, чтобы работало и было сделано в срок. И желательно бесплатно.

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

Когда-то я говорил, что опаздывать на встречи могут только пид$расы. Теперь я сам часто опаздываю на встречи, но в то же время не сплю с мужиками.

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

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

Но сначала история…

Это было <вставьте период времени, который не будет делать меня нелепо старым> в то время, когда я был молодым разработчиком (1). В колледже я был лучшим на занятиях по программированию, будучи младшим разработчиком, я мог взломать код и решить любую поставленную передо мной задачу быстрее, чем кто-либо ожидал. За выходные я мог изучить новый язык и продуктивно на нем работать (или, по крайней мере, мне так тогда казалось).

Таким образом, как и должно было произойти, у меня появился свой собственный проект. Менеджер по работе с крупными клиентами объяснил мне в общих чертах, чего хочет клиент, мы это обсудили, и я сказал: «На эту работу уйдет 3 недели.» «Хорошо», — ответил он. И так я приступил к программированию.

Как вы думаете, сколько времени у меня ушло на этот проект? Четыре недели? Может быть пять?

Мм, вообще-то: три месяца.

У меня остались четкие воспоминания о том времени – мое представление о себе было тесно связано с ощущением, что я — «хороший программист», в чем я сильно разочаровался. Я потерял сон, у меня случались небольшие приступы паники. И этому Не Было Конца. Я помню, что у меня сосало под ложечкой при разговоре с тем менеджером, я снова и снова объяснял, что у меня до сих пор нет ничего, что можно ему показать.

В один из таких черных периодов я решил, что Больше Никогда Не Буду Совершать Подобных Ошибок.

К сожалению, в ходе своей карьеры, я уяснил нечто очень тяжелое: я постоянно совершаю подобные ошибки.

Зародившись как скриптовый язык в помощь веб-разработчикам, с дальнейшим развитием JavaScript стал мощным инструментом разработки клиентской части, обеспечивающий удобство и интерактивность страницы прямо в браузере у пользователя.

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

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

В данном топике будут рассматриваться:

1. Замыкания
2. Прототипирование
3. Контекст выполнения

К слову сказать, на это понадобилось лет шесть изысканий.

Очевидно, что если вы что-то производите (или выполняете проекты, это не так принципиально), то очень-очень хочется делать это:
— быстро
— качественно
— точно в срок
— с минимальными затратами (инвестициями)
Это значит, что должно быть найдено какое-то решение, позволяющее делать именно так.

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

Свои изыскания в этой части мы начали году в 2006-м, полагая, что лучшее решение для производства — это MRP. В 2010-м году, после некоторых опытов по внедрению, мы поняли, что MRP не ведет к увеличению эффективности. Количество заказов, произведенных точно в срок, не увеличивается, запасы не уменьшаются, скорость производства не растет. А зачастую даже наоборот. Я написал статью об этом. Довольно эмоциональную. Видимо серьезно задев тех, кто зарабатывает на внедрении MRP. Но ведь целью внедрения любой системы менеджмента должно быть увеличение эффективности, не так ли? Многие об этом забывают, как, впрочем, и о том, что цель бизнеса – зарабатывать деньги. Поэтому внедрение MRP чаще всего превращается просто в проект по внедрению MRP, а в не в проект по улучшению эффективности производства.

Весной 2012 г., Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике shellx переводит тринадцатое занятие, редактор astropilot.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

Вот, задался таким вопросом… С помощью гугл транслейта и такой-то матери, родилась такая блок-схемка:



картинка кликабельна

Кому нужен сорец (в .docx): тут

Бизнес – это игра или нет? Я думаю да. А у любой игры должны быть правила.

Привет Хабр, меня зовут Александр. Сегодня я хотел бы поделиться с вами о том, как надо или не надо вести бизнес в сфере IT. Данные заметки я извлек из собственного опыта. Я не буду писать здесь книжными и в тоже время, зачастую, пустыми и скучными фразами. Здесь будет только то, что я почерпнул для себя работая на поприще самостоятельной работы, то есть не на дядю. Вся статья будет поделена на части. Во всех частях кроме первой, материал будет изложен в виде заметок, после каждой заметки я буду приводить пример из моей работы, чтобы не быть голословным. Поехали!

Это перевод новой статьи с TechCrunch от Джеймса Альтушера (James Altucher) — инвестора, программиста, автора статей и немного предпринимателя. Его последние книги: Я был слеп, но теперь я вижу и 40 альтернатив колледжу.

Несколько недель назад я опубликовал пост 10 причин, по которым вы бросите свою работу в 2013 году. Там я приводил некоторые доводы. И это не была статья в стиле «Эй, вы должны стать предпринимателем». Скорее рассказ был на тему: недобрая срань творится (bad shit is happening) в корпоративном мире и рано или поздно вам захочется его покинуть.

Конечно же, много людей задавали вопрос: Что дальше? Что мне делать?

«Если люди не могут найти что-то в Google, они думают, что это не сможет найти никто. Это не так», – утверждает Джон Мэзерли, создатель Shodan, самого страшного поискового движка Интернета.

В отличие от Google, который ищет в Сети простые сайты, Shodan работает с теневыми каналами Интернета. Это своего рода «черный» Google, позволяющий искать серверы, веб-камеры, принтеры, роутеры и самую разную технику, которая подключена к Интернету и составляет его часть.

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

Как же они этого добиваются?

Часто считают, что десятикратная производительность вытекает из десятикратных способностей или десятикратных знаний. Я так не думаю. Не хочу сказать, что способности или знания бесполезны. Но за много лет я заметил, что самое главное тут — десятикратная разборчивость. Фокус в том, чтобы постоянно уклоняться от паршивой работенки.

Год назад я начала читать магистрам СПбГЭТУ «ЛЭТИ» маркетинг в рамках курса «Управление ИТ-продуктом», затем расширила аудиторию до слушателей коммерческих и открытых курсов по маркетингу в ИТ.

Не раз мои знакомые (в основном разработчики) спрашивали: «Зачем айтишникам читать курс по маркетингу? Ведь они будут кодить, тестить или поддерживать ИТ-инфраструктуру, в менеджеры проектов и продаж пойдут единицы. Зачем разработчикам знать, что такое маркетинг и PR?».

Я сразу отвечаю очередью вопросов: «Ты долго искал текущую работу? Тебя устраивает твоя зарплата и выполняемые проекты? Ты знаешь, что ожидает от тебя работодатель? Ты делаешь что-нибудь для повышения своего профессионального уровня/имиджа?».

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

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

Добрый день, уважаемые коллеги. В этой статье я хочу поделиться с Вами своими методическими наработками, которые использую в курсе «Теория автоматического управления» на кафедре СУиИ НИУ ИТМО.
Основной задачей, которую я перед собой ставил, было объединение теоретических знаний для решения практической задачи. Такой задачей стало управление приводами Lego робота. Лишний повод поиграть в игрушки, да и студентам проще воспринимать суровый матан… Вот пример описания этого набора: habrahabr.ru/post/166449.

Я всегда с интересом читаю статьи про тестирование кода. И я очень хочу использовать тесты в своих проектах.
Но я не могу. Не могу найти для себя стимул.

Да, тесты из примеров пишутся практически моментально. Но нужно ли писать тест для функции

def get_word():
    return 'word'

вопрос довольно сложный. Написать его не составит проблему, но и пользы от него ощутимой не будет.
Писать такой тест для получения радости от +1 выполненный тест? Не вижу смысла.
Для увеличения покрытия тестами? Не вижу смысла.
Просто так?…

По западной статистике двухлетней давности, 4,7% пользователей выбирают в качестве пароля слово “password”, 8,5% — “password” или “123456”, 10 самых популярных паролей покрывают 14% всей пользовательской базы (40% — топ-100, 79% — топ-500, 91% — топ-1000).

При создании сайта было бы вполне логично составить список общеупотребительных паролей и запретить их при регистрации пользователя. Казалось бы, вполне логичная идея, но… к сожалению, процесс аутентификации в ИТ покрывается множеством патентов, пишет консультант по ИТ-безопасности Марк Бернетт (Mark Burnett). Они описывают самые очевидные, общеизвестные и обыденные техники. Похоже, абсолютно все возможные аспекты выбора пароля, процесса аутентификации, хранения и восстановления информации защищены одним или несколькими патентами.

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

Важные требования к такому забору:

• Никаких изображений!
• Он должен спокойно тянуться по горизонтали
• Обязательно должен поддерживать неравномерный фон у подложки
• Фон не должен требовать никакой экстра-разметки. Лучше всего будет избегать псевдо-элементов (экономия — хорошо).

Поддерживаемые браузеры: Chrome, Firefox (> 3.6), Opera (>= 12), Safari (>= 5), IE10.

Для IE 7, 8 у нас будет фоллбэк в виде обычной заливки. А вот с IE9 проблема — он не поддерживает градиенты, но при этом понимает hsla и rgba цвета. Воистину «великолепный» браузер. Что ж, его пока придётся игнорировать. Если кто–то подскажет хороший фоллбэк для IE буду только благодарен.

В прошлый раз в статье "АСУДД: Что висит над дорогой?" мы бегло прошлись по «железу», которое устанавливается на транспортных магистралях: по типам детекторов транспортного потока, светодиодным табло и дорожным контроллерам.

Сегодня мы продолжим говорить об управлении трафиком, но уже в городе. Рассмотрим из чего состоит цикл светофорного регулирования, чем именно «рулят» управляющие системы и с чего это все, собственно, началось.

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