• Есть ли в Москве какие-нибудь курсы по языку Erlang?

    @lipstick
    Думаю изучать этот эрланг или нет? Узнал о нём ещё в самом начале лихих нулевых, и мне понравилась идея, которая заложена в этом языке программирования, причём, по-моему, изначально никакого OTP и не было в помине, его только потом заопенсурсили.
    Стоит ли переписать все наши наработки на С++? И какой это даст прок? Можно ли сейчас найти специалистов по данному языку? Можно ли пойти на какие-нибудь курсы по его изучению? Если да, то куда? Нижняя Масловка? Якиманка?
    Ориентиром пусть будет магазин элитной пищи «Алые Паруса», сто шагов на север через улицу со светофором, будет жилой дом, позвонить в домофон, там спросят, кто это, а ты ответишь, что это те, кто пришли. Зачем? Учить эрланг. Тебе откроют дверь, на ресепшене выпишут пропуск с гербовой печатью, ты зайдёшь внутрь и шикарная блондинка с могучим торсом будет учить тебя эрлангу, попутно заваривая кофе, но в этот раз всё обойдётся без интима
    Ответ написан
    Комментировать
  • Имеет ли смысл полный рабочий день для программиста? Производительность труда?

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

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

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

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

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

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

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

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

    IIIa66uMEM6eP
    @IIIa66uMEM6eP
    На практике было под 60.
    Ответ написан
    Комментировать
  • Есть ли тут люди купившие подписку на ACM или IEEE и не пожалевшие об этом?

    rfq
    @rfq
    Программист
    Люблю почитать статейки на специфические темы, которых нет в свободном доступе. Подписался на ACM Digital Library и не жалею. На IEEE что-то не получилось подписаться.
    Ответ написан
    Комментировать
  • Есть ли тут люди купившие подписку на ACM или IEEE и не пожалевшие об этом?

    strib
    @strib
    IEEE + Comunications Society + Computer Society. Не жалко.
    1) Пускают к работе над стандартами.
    2) Доступ к приличному количеству материалов
    3) Все таки надо в этом году съездить на конференцию
    4) Постоянно присылают всякие отраслевые вебинары, события итд. Сам бы я их не нашел, многое полезно.
    Ответ написан
    Комментировать
  • Есть ли тут люди купившие подписку на ACM или IEEE и не пожалевшие об этом?

    grossws
    @grossws
    Недавно купил подписку ACM (если будете оформлять, учтите, что для РФ сниженные тарифы), для prof. member $20 за электронную подписку и $40, если хотите ещё и бумажную копию CACM. Если хочется больше — есть подписка за ~$100, которая даёт доступ к цифровой библиотеке:
    ACM Professional Membership PLUS the ACM Digital Library includes a print and online subscription to Communications of the ACM, access to online courses, ebooks and training videos, subscriptions to MemberNet, TechNews and CareerNews, the ACM Career and Job Center, PLUS unlimited access to the ACM Digital Library, and all the benefits of ACM Membership.


    Есть интересные вещи. Предоставляют доступ к довольно большому количеству материалов. Но к старым выпускам журналов доступа не дают, если нет подписки на Digital Library.
    Ответ написан
    1 комментарий
  • Есть ли тут люди купившие подписку на ACM или IEEE и не пожалевшие об этом?

    @tasman
    Я покупал будучи студентом подписку на IEEE. По-моему если нет планов ехать на их конференции — смысла особо нет. Для конференций там довольно большие скидки.
    Доступа к статьям из ieeexplorer бесплатно нет, их надо покупать отдельно (но тоже дешевле, если я не ошибаюсь).

    В общем подписывался два года, а потом понял что лично для меня смысла нет.
    Ответ написан
    Комментировать
  • Программу для продвинутого редактирования текстов?

    @victor1234
    IT: Компьютерное зрение, linux, с++
    Vim наиболее мощный, но если вы не программист, то он покажется излишне сложный и непонятный. В этом случае Notepad++. Небольшой, быстрый, есть плагины.
    Ответ написан
    1 комментарий
  • Чем пользуетесь для ведения домашней бухгалтерии?

    oleksa
    @oleksa
    Personal Finances. Пару лет уже. Просто и очень удобно. Настолько помогает, что отблагодарил автора покупкой лицензии.
    Ответ написан
    Комментировать
  • JS. Централизованная обработка ошибок

    alienator
    @alienator
    Никто за вас не решит, что лучше.

    Конечно, можно и нужно иметь try/catch на самом верхнем уровне. И дать ему какое-то полезное поведение — записать в лог, вывести красивое окошко и т.п., чтобы не пугать пользователя системными сообщениями.

    Это необходимый минимум.

    А дальше смотрите глубже. Что вам даст функция-обработчик внутри объекта исключения? Во многих случаях она уже бесполезна; она слишком далеко от точки возникновения ошибки, чтобы попробовать ее исправить (например, вызвать код повторно со значением по умолчанию, подождать освобождения ресурса и т.п., короче, какой-нибудь while/try).

    Перед каждым вызовом функции, которая может выбросить исключение, перед каждым входом в компонент у вас есть три пути:

    • обработать какие-то (или все) исключения здесь
    • обработать и передать выше (повторный throw)
    • ничего не делать (передать сразу наверх)


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

    И вот там, поглубже, внутри компонента, уже действует ряд разумных рекомендаций:

    1. Не ловить всё подряд. Обрабатывать только те исключения, с которыми известно, что делать. Если не совсем известно, делать re-throw.

    2. re-throw делать аккуратно. Не надо, опять же, хватать больше от жадности, а потом пропускать исключения ненужных классов. Для ява-скрипта это выражается вот в чем:

    Нехорошо:
    try {
         // ...
    } catch (e) {
         if (! e instanceof MyError) {
              throw e;
         }
        // ...
    }
    


    Хорошо:
    try {
         // ...
    } catch (e if e instanceof MyError) {
        // ...
    }
    


    3. То, что вы делаете в finally, важнее, чем то, что делаете в catch. Есть что подчистить — надо подчистить.

    4. Не надо терять информацию об ошибке (генерить или ре-генерить исключение более широкого класса). Правда, при разработке либы лучше наоборот, свои мелочи держать в себе и заменять низкоуровневые ошибки на более общие.

    Ну, что хотел сказать, то сказал. Удачи.
    Ответ написан
    3 комментария