Многие менеджеры в приватных беседах жалуются на сотрудников. Вроде бы и знающие специалисты, а работу не работают. Более того — часто отнимают время у тех, кто таки работает. Хоть увольняй.
Многие родители жалуются на что-то подобное в отношении детей. И тут уволить уже нельзя.
И сотрудники, и дети, часто действуют похожими способами. Реализация разная, а виды действий — схожие:

• Привлечение внимания
• Борьба за власть
• Месть и личные нападки
• Беспомощность

У каждого из этих видов есть свои формальные признаки и стандартные лекарства.

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

Фаза «предразработки» приложения

Прежде чем приступить к реализации вашей идеи вы должны задать себе пять вопросов:
1. Кто будет использовать ваше приложение?
2. Какие у вас конкуренты?
3. Почему ваше приложение уникально?
4. Когда вы его выпустите?
5. Как люди будут взаимодействовать с вашим приложением?

Рассмотрим каждый вопрос по отдельности.

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

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

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

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

На Stackoverflow часто встречаются вопросы по выполнению на Android фоновых задач, в т.ч. и повторяющихся с заданным промежутком времени. Как правило, первое, что используется, это Service.

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

Вы подписаны на блог GTD? Вас волнуют проблемы концентрации? Вы составляете распорядок дня, план на неделю, стратегию на месяц, но вечером внезапно <вставить внезапное> до самой ночи, а утром не можете встать? Всё очень плохо. А если вы знаете значение слова прокрастинация (хотя, справедливости ради, кто на хабре его не знает?), то это практически клинический случай. По крайне мере, все и вся вокруг, осознанно и не очень, пытаются нас в этом убедить, ну или просто говорят об этом… ну или молчат, но думают!

^{Внимание! Статья не содержит чудо рецептов, не сделает более внимательным или работоспособным. Думаю даже не расскажет о чём то, о чём вы до этого не думали.
Фактически, вся статья — это досужее рассуждение на тему (и не очень).
Однако, все совпадения с реальными людьми и событиями не случайны, и автор несёт всю полноту и меру ответственности за всё выше и ниже сказанное, поэтому, если какой либо абзац, предложение или слово кажется вам оскорбительным — не стесняйтесь выражать своё мнение в моей карме.
Так же позволю себе использовать аббревиатуру GTD в широком, а не конкретном смысле.}

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

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

Итак, если есть желание посмотреть на математические формулы и куски кода на C++ в последние дни лета, то добро пожаловать под хабракат.

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

В статье будут описаны нюансы настройки IP-телефона Cisco на примере цискофона 7942G.
Итак, если вы присматриваетесь к VoIP-устройствам Cisco серии 79XX, то добро пожаловать под кат.

О проекте

Я увлечён фотографией. А ещё мне нравится собирать всякую электронную мелочь. Наверное, из-за этого я чувствовал, что просто обязан попробовать сделать скоростной фотоснимок. Эдвард Мейбридж баловался такой фотографией ещё в позапрошлом веке. В этом посте я расскажу об основах скоростной фотосъёмки и о том, как я собирал свой фото-триггер.

Введение

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

Я хочу рассказать о том, как собрать такую штуку дома.

Введение

Добрый день.
Использую, как и многие, крупный торрент-трекер — rutracker.org, однако есть одна особенность которая меня раздражает.
Это добавление в список трекеров адреса ix*.rutracker.net, который служит для непонятных мне целей. Однако который часто (у меня — практически всегда) выдаёт ошибки (502 Bad Gateway и 0 No Response). Торрент-клиент (у меня Transmission) помечает торрент сломанным. Что само собой довольно сильно мне мешает. Особенно если учесть особенность Transmission — она задаёт статус торрента по последнему ответу трекера. То есть опрашиваем ix*, он возвращает ошибку, торрент помечается как Broken, через n минут/секунд опрашивается следующий трекер из списка — bt*.rutracker.org или retracker.local, которые возвращают успешный код и торрент снова становится нормальным. Такая чехарда не особо меня радует.

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

С 13 по 15 мая в Москве пройдет четвертая конференция YAPC::Russia, посвященная языку программирования Perl и его сообществу. В этом году конференция совмещена с ежегодным украинским Perl-воркшопом Perl Mova.

Трехдневная программа состоит из хакатана по Perl 6 и докладов про современные версии языка и приложения на их основе.

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

Основы

Мы начнём с несложного обзора модульного подхода, хорошо известного с тех пор, как Эрик Миралья (Eric Miraglia) из YUI впервые об этом написал. Если вам уже знаком модульный подход, переходите сразу к «Продвинутым техникам».

Анонимные замыкания

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

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

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

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

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

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

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

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

Сообщество JavaScript в курсе этого, особенно сообщество Node.JS, так как Node.JS ставит акцент на асинхронном коде.

Майкл Шрёпфер (Michael Schroepfer, вице-президент по разработке Facebook, в прошлом — вице-президент по разработке Mozilla) прочитал советы по выживанию программиста в Google и решил вкратце высказать своё мнение об основных ошибках этой компании по управлению инженерией (engineering management).

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

При 1500 сотрудников в Google было больше гибкости и меньше бюрократии, чем в большинстве стартапов на 200 человек. При любом размере Google был лучшим местом для работы среди компаний своего класса. При текущем размере Google — всё ещё более привлекательное место для работы, чем Oracle, Cisco, Microsoft, Adobe, Apple и многие другие хорошо известные фирмы. Именно это делает ошибки менеджмента более заметными.

Топик навеян впечатлениями от докладов на swpiter и постом о том, как не продать машину :)

Как работать над стартапом и всегда оставаться в выигрыше?

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

Картинка слева кликабельна, а ниже — текстовое описание в 12 шагах как инициировать стартап и при этом всегда оставаться в выигрыше.

1. Идея!

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

Самое важное в идее — это не терять мотивацию вплоть до 10 шага и тогда вы в любом случае получите для себя выгоду.

2. Детализация идеи

Необходимо хотя бы примерно ответить на эти вопросы:

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

На этом этапе ещё рано отвечать на вопросы:

• сколько времени вы можете уделить (если идея вас реально интересует, вы перейдёте к следующим этапам)
• сколько на это нужно денег
• кто вам ещё нужен для реализации идеи

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

Итак, проблема: люди нового поколения (компьютеров, интернета, мобильных телефонов) не могут сосредоточиться. Не новая мысль, правда? Слишком много раздражающих факторов, скажете вы и… будете правы! Но проблема от этого не уменьшится.

Давайте попробуем выделить основные:
1. Мобильник. Мы настолько с ним сжились, что выходя из дома без него чувствуем себя раздетыми, брошенными и беззащитными. Мобильник ловит в метро, в горах, в Карелии и Селигере. Мы «все время на связи» — круто! Тотал контрол.

2. Интернет. Рассадник мелких раздражителей: мессенджеры, почта, твиттер, форумы, блоги :) И вообще, в инете столько всего интересненького! А теперь все это многообразие вообще все время в любимом коммуникаторе с красивым экраном и приятном на ощупь — ну как тут отказаться?

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

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

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