snp

Как вы думаете, на сколько это эффективно в плане производительности, нежели допустим 5 часов?

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

Вопрос крайне интересный. Но я бы поставил его не так — не как заставить программиста дольше работать, а как сделать так — чтобы он больше делал. Т.е. организовать эффективную работу. По опыту — удавалось повысить производительность программистов раз в 10, а аналитиков почти в 12 (!). Как?

Во-первых — проанализировав процесс и устранив все точки, где возможен re-work, переделка ранее сделанной работы. Например слабый аналитик не разобрался в требованиях заказчика и вывалил весь это мусор на кодировщика. В итоге противоречия в голове заказчика и аналитика привели к противоречиям в коде. Как устранить? — проапгрейдить аналитика, сделать формальным процесс обследования, ввести приемку BRD старшим аналитиком.

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

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

В четвертых, порядок коммуникаций. Возьмите за правило — не дергать программера чаще чем в 2-3 часа. Как правило он думает в «туннельном эффекте» — декомпозируя задачку и входя в режим творения. На такую подготовку уходит 20-30 минут. Если его в этот момент выдернуть тупым вопросом — мол, дай сигарету или ты не знаешь — а где лежит постановка — то опять потребуется полчаса…

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

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

Ситуация малоприятная, но терпимая.
Возьмите больше информации с помощью smartmontools: sourceforge.net/apps/trac/smartmontools/wiki

Обратите внимание на параметры: Reallocated_Sector_Ct, Power_On_Hours, Current_Pending_Sector

Reallocated_Sector_Ct — количество секторов, которое было переназначено в резервную обрасть. Если значение растет — значит диск посыпался и его нужно срочно менять.
Power_On_Hours — и так понятно. Время, которое диск «налетал»
Current_Pending_Sector — количество серверов, которые диск обозначил как нечитаемые. Диск не смог прочесть данные с конкретного сектора и позначил его сбойным. При записи в него «пендинг» может уйти и сектор вновь станет читаемым, либо диск его переназначит в резервную область (Reallocated_Sector_Ct)

Достаточно указать эти три параметра в качестве причины, чтобы саппорт провел замену диска.
Для замены диска укажите модель, серийный номер и возможный номер корзины (в которую диск установлен). Серийник и модель получите из smartmontools, хотя они у Вас уже есть.

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

В целом все

>слушает только localhost:25
некоторые мыльники проверяют доступность отправляющего хоста на 25 порту, так что, лучше открыть снаружи, просто не принимать письма.

За то, что, код можно прочитать в слух, и код от этого не потеряет ясность.
За то, что англо-русский словарь нужен для именования переменных
За то, что именование переменных и выбор общего алгоритма — едиснтвенное о чем приходится думать.
За то, что при программировании на Ruby 99% уходит на проектирование поведения, и 1% на программирование
За то, что по первой строке ошибки можно определить где и в чем ошибка
За то, что интеграционные тесты можно писать на русском, от чего заказчик обливается слезами умиления и расстается с деньгами
За то, что вызывает ООП головного мозга
За то, что технилогический уровень, и технологическое качество на голову выше программы ВУЗ-ов
За то, что высокий порг вхождения по IQ на нет сокращает количество быдлокодеров
За то, что разработка вызывает просто животный восторг граничащий с оргазмом
За то, что разработкой в кайф реально можно заниматься по 16 часов в сутки и не сломать себе мозг
За то, что на форуме тебе не скажут: лол ты нуб иди читай маны днище!!111адинадин
За то, что, возможно, ваше изящное решение еще никто не использовал
мне на работу пора, а так я могу очень долго писать

+ Ясность, краткость и выразительность языка: наличие очень мощных библиотек для работы с текстом, массивами, простая работа с файлами, ну и так далее.
+ В целом, как я заметил, достаточно хорошая культура разработчиков к написанию качественного и лаконичного кода, покрытие тестами, возможно, это объясняется достаточно высоким уровнем самих разработчиков.
+ Большой набор библиотек на разные случаи жизни, при этом они все достаточно актуальны и их стараются поддерживать. Если поддерживать перестают, то делают форк, либо появляется иной проект.
+ Ruby on Rails — я считаю это киллер фичей, расписывать про него не буду, в инете и так вагон материала.
+ Достаточно большое сообщество разработчиков.
+ Полностью объектно-ориентированный, но при этом позволяет писать в псевдо-процедурном стиле, а также в функциональном.

> можно спокойно вытащить батарейку, поставить ее обратно
А если вытащить, подождать пару недель и только потом вставить обратно?

Если вы не Юлий Цезарь, и не собираетесь работать одновременно в трех документах, параллельно редактируя документы в фотошопе — два монитора за глаза. Все равно внимание только на одном из них сконцентрировано.

Сугубо личное мнение основанное на моих потребностях: минимум два монитора.
Один — для кода, второй — для браузера.
Еще лучше — три:
1. код
2. браузер
3. developer tools

Установить диск побольше.
Ваш КО

Если вы пишите на чем-то вроде Haskell или Scala и функция чистая, то в случае ошибки должны возвращать None, а в случае успеха Some(X). То есть, использовать тип Maybe или Option. Если функция не чистая или вы пишите на неправильном языке, нужно бросать исключение.

Есть стандарт UUID. На его основе сделайте свой.

К счастью на моей работе, если нет аврала, могу выделить часик на почитать чего-нить новенькое + законный обед. Иногда часик размазан на весь рабочий день…
Ну и вне работы coursera.

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

Главное — DVCS, т. е. Git или Mercurial. Централизованная система всегда хуже распределённой.
Дальше уже дело вкуса. Я предпочитаю Гит, но это потому, что я хорошо его знаю ;) Говорят, что у Меркуриала ниже порог вхождения, но для Гита есть прекрасная книга: Pro Git, которая позволяет быстро войти в курс дела…

На Хабре уйма статей про VCS, со сравнением и священными войнами в комментах.
Я бы сразу вычеркивал из этого списка SVN — централизованная система со всеми присущими ей проблемами (упал сервак — потеряли код; нет копии сорцов у каждого разработчика и т.д.), нелогичное ветвление (считай, его отсутствие) и прочее.

Выбирать есть смысл из Git и Mercurial. На гите сидит больше народу, есть куча мануалов, howto, обучалок и прочего. Если интересует свой корпоративный сервак, есть отличный фронтенд Gitlab, а если разрабатываете opensource или есть деньги, можно захоститься на популярном Github.
Для Mercurial есть замечательный Bitbucket (хотя, git они тоже поддерживают).
Удобства работы с консолью, ровно как и работа с GUI для этих систем я бы поставил на один уровень.
Идеологически системы по-разному хранят историю. На гите огромные репозитории (от 1Гб, хотя для Вас это вряд ли актуально) работаю плохо из-за хранения полных слепков файлов, на mercurial хранятся мелкие изменения, поэтому репозитории не такие жирные. В целом, для подавляющего большинства проектов на эту разницу можно забить.

Я использую Git, и не имею с ним никаких проблем. Очень хорошая, продуманная и быстрая VCS.

Вы знаете, я никогда особо не парился с разложением данных.

Попробуйте распределить сперва пространство на работу и leisure time.

Ни в коем случае не надо создавать папок downloads или «разобрать».

Я пришел к выводу, что чем узкоспециализированней папка, тем лучше. А вообще, структуризация и учет весьма непростая вещь. Надо себя сильно дисциплинировать.

Не уверен помогло ли, но удачи Вам!

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

для установки на свой сервер:
rnews.sourceforge.net/
github.com/gothfox/Tiny-Tiny-RSS

Засел бы за Go или всерьез вернулся к OpenGL в плане кроссплатформенного gamedev'а.