Давным давно в одной из компаний, лидере мирового производства микропроцессоров, меня однажды поразила менеджерская напасть. Решил, знаете ли, заняться развитием сотрудников. (Периодически, такое с менеджерами случается, да.)

Подхожу к своему сотруднику — назовем его Серега:

— Серега, — говорю, — ты в какую сторону вообще хочешь развиваться: в техническую или в менеджерскую?

— Сань, ну голова варит уже не очень, возраст… (Серега старше меня на 3 года) Поэтому, наверное, в менеджерскую.

Ну, в менеджерскую — так в менеджерскую. Я ж на тот момент был менеджер опытный, уже 4 года опыта! Энергии много, желания помочь людям — через край!

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

А кончилось все тем, что пришлось нам с Серегой расставаться. Как так получилось, где Серега в итоге реализовал себя, и какой правильный управленческий инструмент я мог бы тогда применить — об этом сегодня и поговорим.

Заодно поговорим, что делать, если вы обнаружили себя и/или своих сотрудников в квадрате C в статье:

• Управленческие инструменты: Как играть в нелинейные шахматы

AmBAR и SiliconNews.ru взяли интервью у основателя компании Evernote (также, легендарных ParaGraph и Parascript), оценка которой уже превысила 2 млрд. долларов. Очень интересный человек с интересной историей, у которого есть чему поучиться. Эксклюзивное интервью, где, помимо прочих фактов, Степан Пачиков впервые делится своими неудачами в бизнесе.

Степан Пачиков: русский новатор, сооснователь компаний ParaGraph Intl., Parascript, Evernote, которые внесли большой вклад в развитие распознавания рукописного текста и технологии VRML (язык моделирования виртуальной реальности, стандартизированный формат файлов для демонстрации трёхмерной интерактивной векторной графики, чаще всего используемый в WWW). Первый бизнесмен СССР, чья фирма [ParaGraph] получила контракт с Apple.

Иван Цыбаев: Поговорим сначала о Кремниевой Долине. У вас есть замечательная вдохновляющая статья «Кремниевая Лихорадка» от 95-го года в "Огоньке". Как она была написана? Под каким впечатлением? Был какой-то особый этап в знакомстве с Долиной?

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

Лекция рассчитана на старшеклассников – студентов Малого ШАДа, но и взрослые смогут почерпнуть из нее много полезного.



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

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

Неделю тридцатистрочников на JS стоит разбавить чем-нибудь действительно ненормальным.



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

Если есть вопросы, предложения или исправления к коду — добро пожаловать в комментарии.

Статья по мотивам Построение системы аналогового видеонаблюдения непрофессионалами.
Продолжение этой статьи: Система цифрового видеонаблюдения 2. Видеорегистратор, ПО и нагрузочное тестирование

Задача: оборудовать СТО системой видеонаблюдения. Доступ к live-изображению из нескольких рабочих мест. Желательно иметь доступ к камерам через смартфон (для контроля в случаи командировки).

Примечание: вся система внедрялась в процессе строительства СТО. Помимо видеонаблюдения устанавливали рабочие станции пользователей, сервера, оборудование для автоматизации и т.д. Но остановимся только на части про видео.

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

15 лет назад, 19 ноября 1998 года вышла в свет первая игра из серии Half-Life от молодой компании Valve. Уже выросло целое поколение на играх того времени и HL действительно был прорывом в тот момент. Half-Life до сих пор остаётся наиболее успешной игрой жанра, продавшись количеством в 20 миллионов копий.

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

Мы продолжаем делиться с обитателями Хабра кратким изложением выступлений гостей финала Russian Code Cup 2013. Сегодня мы представляем вашему вниманию конспект рассказа Дмитрия Склярова о реверс-инжиниринге.

Дмитрий Скляров — доцент кафедры информационной безопасности МГТУ им. Баумана и аналитик компании Positive Technologies. Работает в области информационной безопасности более 13 лет. Разработчик алгоритма программы Advanced eBook Processor.

Реверсинг — это, конечно, не самая простая дисциплина из области IT. Тем не менее, чтобы получить результат, то есть понять, что делает программа, не всегда необходимо анализировать каждую строчку кода и каждую ассемблерную команду. Иногда достаточно ряда простых логических умозаключений и умения «думать как программист». Понять, что я имею в виду, нам помогут два примера анализа, взятые из моей практики.

На одной из конференций произошел комичный случай. Подходит слушательница:

— Александр, есть такой вопрос: Как нам повысить уровень доверия в отношениях с заказчиком?

— А что сейчас не так с уровнем доверия?

— Ну, у нас есть команда, есть менеджер. И мы хотим, чтобы заказчик доверял команде и общался только с менеджером. А он лезет напрямую к инженерам…

— А чем это плохо? Человек сразу получает ответы на свои вопросы, быстрые коммуникации и все такое.

— Понимаете… Мы ему джуниор инженеров продаем как синьор инженеров… И нам не хотелось бы, чтобы он обнаружил этот факт.

Напомню изначальную постановку вопроса: “Как нам повысить уровень доверия в отношениях с заказчиком?”

Вот о заказчиках сегодня и поговорим. А точнее, о простом инструменте, который:

• Поможет осознать, где находятся ваши отношения с заказчиком
• Покажет, почему формы отчетов иногда бывают такие идиотские
• Возможно, поможет понять причины “неадекватного” поведения заказчика

1. Что такое IEMs?

Внутриканальные наушники (англ. In-Ear-Canalphone), еще именуемые как затычки, реже ухо-мониторы или (правильное) IEMs (в дальнейшем в статье будет именно это название, т.к. оно очень лаконичное и нравится автору) — это наушники, внешне очень похожие на вкладыши, но разработанные для максимальной звукоизоляции ушного канала слушателя. Ее (звукоизоляцию) еще называют, звуковая «герметизация», — она имеет две функции: блокировка лишних шумов и формирование звуковой площади (камеры) для достижения полноты звучания. Создает такую герметизацию насадка, надетая на сопло наушника и вложенная в переднюю часть ушного канала. Существуют также наушники, где насадка создана по слепкам ушей владельца, — они называются (у русскоговорящей аудитории) кастомами (англ. Custom molded earplugs), — подобные вещи служат для достижения максимального качества звука и комфорта от прослушивания.

Почему выбирают IEMs? Из-за высокой портативности, качественного звука и способности к блокировке лишних шумов. Некоторые модели уже давно используют аудио-инженеры; музыканты, выступая на сцене. Затычки (в России это название прижилось больше), являются разновидностью IEMs. Когда производители внутриканальных наушников начали клепать их для общего потребителя (поколение iPod), аббревиатура IEMs стала более популярна (не в России), заменив выражение «затычек».  Техническим языком правильно «затычки» называть — IEMs. Реже аббревиатура IEMs используется для обозначения внутриканальных наушников высокого качества.

О чём расскажет этот пост?

О том, как использовать старый сканер вместе с сервером под Debian для сканирования при нажатии кнопки, да ещё и с автоматической сортировкой.

Зачем это нужно?

Это подходит всем, кого не устраивают завалы бумаги на рабочем месте. К примеру:

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

Как я себе это представляю?

Да очень просто. Положил бумажку в сканер, нажал кнопку, дождался звукового сигнала о конце сканирования и обработки, вынул бумажку, при необходимости — GOTO 10.

И что у меня вышло?

Бесперебойно работающая система, которая также позволяет пакетное сканирование и автоматическую сортировку по папкам, логирование и прочие заморочки — что в скрипт впишешь, то и будет.

Доброе время суток!
Расскажу я как можно собрать себе радиомодем мощностью 100мВт на 433МГц, по стоимости выходящий примерно на 6-7 долларов. Мощный радиомодем за 200 рублей — заманчиво? Тогда начнём.

Требуются скиллы пайки немного выше среднего и опыт заказа в интернет-магазинах.

«Человек добился успеха, если он встает утром и ложится спать вечером, а в промежутке занимается тем, чем хочет»

— Боб Дилан

Я – программист по образу жизни. Я в одиночку работаю программистом, чтобы обеспечить себя интересной, полезной, гибкой и хорошо оплачиваемой работой. У меня нет инвесторов, я не собираюсь нанимать сотрудников, не говоря уже о том, чтобы стать следующим Google или Facebook. У меня нет личного самолета, и мое лицо вряд ли скоро появится на обложке Newsweek. Меня это устраивает.

История

Внедрение Linux в ПриватБанке началось в 2007 году. За это время был пройден большой путь и хотелось бы поделиться с сообществом своим опытом внедрения. На данный момент мы достигли следующих показателей: более 36500 рабочих мест с ОС Linux в 4000 отделений, расположенных в 5 странах.
В 2007 году за основу был взят ASPLinux 11.2. Со временем для альтернативы были выбраны другие дистрибутивы — Fedora, openSUSE, Ubuntu. Позже стала очевидной необходимость создания собственного дистрибутива и системы управления рабочими станциями. Разработка началась в январе 2012 года. Для основы был выбран Ubuntu 12.04 LTS с рабочим окружением Gnome Classic (no effect). Основные аргументы: Ubuntu — самый распространённый десктопный дистрибутив последних лет; обширное комьюнити, где проще найти решение возникающих проблем; именно его в качестве основы внедрения выбрал Google, много примеров внедрения в государственных и муниципальных учреждениях Германии, Франции. Выбор системы управления остановился на Puppet.
В июне 2012 года стартовал переход и к январю 2013 на корпоративную ОС были переведены уже около 95% ПК. Такая скорость перехода обусловлена тем, что сотрудники уже имели опыт работы в Linux.

Основные задачи, которые удалось решить благодаря текущему внедрению:

• cущественная экономия ресурсов при поддержке ОС на рабочих местах сотрудников;
• поддержание программного обеспечения в актуальном состоянии;
• возможность оперативного применения критических обновлений (до 1 часа на всех ПК);
• cбор и анализ статистической информации о парке ПК и периферии;
• создание системы проактивной реакции на сбои (Event Manager).

Дальше более детальное описание компонентов нашей реализации.

Автор фотографии: Максим Золотухин

Привет Хабр! Хочу рассказать вам о небольшом сообществе junior-разработчиков в Алматы и своём пути junior-разработчика в Казахстанском вебе.

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

Искал в гугле «солнечная панель 100 Вт» и в первом десятке выдается ссылка на Хабрахабр, статья от 2011 года. В комментариях правильные вещи, но актуальностью на сегодняшний день — бред. Сегодня солнечная панель 100 Вт (на Украине) стоит до 100 долларов, контроллеры, аккумуляторы — все это не очень напряжно. Но самая большая загвоздка зеленого прогресса в том, что люди просто не понимают, что такое солнечная энергия, как правильно и по уму все реализовать, зачем это надо и вообще…

Не в рекламных целях. Я торгую на рынке солнечными панелями и 90 человек из 100 отталкивают это новшество, как отталкивали мобильники 15 лет назад — дорого, не нужно, не выгодно, и так хорошо. Многие хотят набрать панелей по 100 долларов на 10 килоВатт и не платить за электроэнергию. Сами посчитайте — 100 Вт х10 = 1кВт * 10 = 10 кВт = 10 000 долларов. Это только на панели, без аккумуляторов и контроллеров. Аккумуляторов на час работы нагрузки в 10 кВт надо еще 12-13 шт по 100 А/ч (еще по 200 долларов каждый) и т.д. В итоге, смотрят на продавца как на идиота, выбрасывают из головы все, что им рассказываешь и в этой самой голове остается одно: «мне это не интересно». На самом деле все обстоит немного иначе.

Зачем созданы солнечные панели? В чем смысл жизни человека? Почему мы дышим грязным воздухом? Спаси планету, освободите Вилли!

На эти вопросы может быть множество ответов, постараюсь изложить более-менее понятно как это вижу я.

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

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

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

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

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

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

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

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

Так вот — каждый раз, когда я встречал очередного «чего там работать, сделайте как в фейсбуке» клиента, я давал себе слово, даже нет – я клялся могилами предков, что вот уж я бы на его месте так себя не вел. Я бы на его месте работал так, что разработчик еще и приплачивал бы за удовольствие иметь со мной дело. Уж я бы на его месте мог бы стать просто самым лучшим заказчиком. И однажды я им стал.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы могут показаться читателю чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он окажется полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Опубликовано ранее:
Часть 1

Сложность

Из предыдущей части можно сделать вывод, что если мы сможем отбросить все эти декоративные константы, то говорить об асимптотике функции подсчёта инструкций программы будет очень просто. Фактически, любая программа, не содержащая циклы, имеет f( n ) = 1, потому что в этом случае требуется константное число инструкций (конечно, при отсутствии рекурсии — см. далее). Одиночный цикл от 1 до n, даёт асимптотику f( n ) = n, поскольку до и после цикла выполняет неизменное число команд, а постоянное же количество инструкций внутри цикла выполняется n раз.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы покажутся чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он будет полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Введение

Многие современные программисты, пишущие классные и широко распространённые программы, имеют крайне смутное представление о теоретической информатике. Это не мешает им оставаться прекрасными творческими специалистами, и мы благодарны за то, что они создают.

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