«Думаю, я смело могу сказать, что квантовую механику никто не понимает», — Ричард Фейнман

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

Привет, Хабр. Я редактор в компании Ratio, мы делаем веб-разработку на заказ и с начала 2018 года все наши сотрудники работают удалённо. От Таллина до Комсомольска-на-Амуре, семь часовых поясов.

Наши разработчики всегда трудились из дома, но также был офис в Москве, в котором сидела часть менеджеров. Мы настроили бизнес-процессы так, чтобы работать на удалёнке было удобно, так что со временем офис опустел сам собой — закрыли его без проблем с дисциплиной и дедлайнами.

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

История реальная, я все видел своими глазами.

Несколько лет один парень, как и многие из вас, работал программистом. На всякий случай напишу так: «программистом». Потому что он был 1Сником, на фиксе, производственной компании.

До этого он пробовал разные специальности – 4 года во франче программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения своей кавычечной профессии – программиста 1С.

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

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

В 1933 году шведский офтальмолог H. Sjogren впервые описал синдром «сухого глаза» при одноименном синдроме Шегрена (аутоиммунное заболевание, при которой снижается секреция слюнных, слезных и др. желез). Это так называемый первичный синдром «сухого глаза», который наблюдается у 1% населения. Развитие современных технологий позволило в 1995 году выделить вторичный синдром «сухого глаза» которым, по разным данным, страдает до 20% населения, и до 48% офисных работников.

Что же это за болезнь?

Когда мы моргаем, мы не только смачиваем роговицу глаза слезой, но и оставляем на ней «слезную пленку». В норме она сохраняется на глазу от 10 до 45 секунд, потом лопается. Мы моргаем снова и процесс повторяется.



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

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

— Даю тебе пять минут, — раздалось в наушниках. Голос Джулии с трудом пробивался через помехи — он отъехал от станции чересчур далеко.

— Мне достаточно трёх.

— Уверен?..

— Ты издеваешься? — завопил он в микрофон.

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

Многие люди представляют функциональное программирование как нечто очень сложное и «наукоемкое», а представителей ФП-сообщества – эстетствующими философами, живущими в башне из слоновой кости.

До недавнего времени такой взгляд на вещи действительно был недалек от истины: говорим ФП, подразумеваем Хаскель и теорию категорий. В последнее время ситуация изменилась и функциональная парадигма набирает обороты в web-разработке, не без помощи F#, Scala и React. Попробуем взглянуть на «паттерны» функционального программирования, полезные для решения повседневных задач с точки зрения ООП – парадигмы.

ООП широко распространено в разработке прикладного ПО не одно десятилетие. Все мы знакомы с SOLID и GOF. Что будет их функциональным эквивалентом?.. Функции! Функциональное программирование просто «другое» и предлагает другие решения.

Вот уже некоторое время я обдумываю идею написать книгу о теории категорий для программистов. Не компьютерных теоретиков, программистов — скорее инженеров, чем ученых. Я знаю, что это звучит безумно, и я сам достаточно напуган. Я знаю, что есть огромная разница между наукой и техникой, потому, что я работал по обе стороны баррикад. Но у меня всегда был очень сильный порыв объяснить вещи. Я восхищаюсь Ричардрм Фейнманом, который был мастером простых объяснений. Я знаю, я не Фейнман, но я буду стараться изо всех сил. Я начинаю с публикации этого предисловия, которое должно мотивировать читателя изучить теорию категорий, и надеюсь на начало дискуссии и обратную связь.

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

Ты ж компьютерщик, какой роутер домой купить? Обычный такой вопрос, который постоянно задают любому человеку мало-мальски связанному с IT. Причем, все объяснения про диапазоны, каналы и прочее сводятся к первоначальному вопросу – это, давай попроще, какой купить, чтоб быстрый и брал везде.



На самом деле, задача гораздо интереснее, чем кажется. В большинстве случаев сферическому пользователю нужна машинка, которую он настроит единственный раз в жизни, она станет легко «добивать» до дальней комнаты и удовлетворять его постепенно повышающимся потребностям лет 5. Самое смешное, что большинство обзоров роутеров не дает ответа на эти вопросы и исходит из какой-то другой, я бы сказал, альтернативной логики. Смотрите, вот мы протестировали скорость в 4 потока на нашем крутом тестовом стенде с роутером, который находился на расстоянии 3 метра от компьютера. Круто! А что с обновлениями, что со стабильностью, что с той же скоростью при передаче на большие расстояния? Тишина.

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

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

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

Масштаб

• Разработка программного обеспечения для государственного агентства.
• Сложность низкая, с несколькими вывертами.

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

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

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

Чувствуете, что готовы уйти с работы, самостоятельно контролировать свой день, биться за клиента и работать только над интересными задачами? Пришло время попробовать себя во фрилансе. Это совсем нелегко, а чаще труднее, чем офисная рутина. Чтобы не разочароваться в выборе формата работы, устройте себе тест-драйв — на праздниках или в выходные. Собрали площадки, где найдете задачи по душе.

Изначально проект PUBG (просим прощения у оригинальной PUBG за использование их аббревиатуры, мы всего лишь хотим использовать эту игру для развития навыков программирования и не планируем публиковать ее в Steam в будущем) был разработан как внутренний проект нашей студии для развлечения. Затем же мы подумали, что он может быть полезен другим студиям, компаниям и образовательным учреждениям, и опубликовали его под лицензией MIT.

В сегодняшней подборке вы найдете статьи и подкасты с руководствами из нашего «Мира Hi-Fi».

В нее вошли материалы о ПО, железе, наушниках, усилителях — обо всем, что полезно знать о них меломану. Здесь мы собрали тексты о самых разных аспектах аудио: от специализированной аппаратуры до «компьютеров для Hi-Fi», и от винила до MP3.

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

Говорят, бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и как работают другие люди. То есть, идеальный объект для наблюдений — прямая трансляция большой конференции.

И кстати, у нас есть для вас одна такая. В это воскресенье и понедельник проходит DotNext 2017 Moscow — крупнейшая в России конференция, посвященная разработке на платформе .NET. Три десятка спикеров выступят с докладами о настоящем и будущем платформы .NET, об оптимизации производительности и многопоточности, о внутреннем устройстве платформы .NET и CLR, о профилировании и отладке .NET-кода, и так далее.

И у вас есть возможность поучаствовать в этом — без необходимости куда-то лететь или ехать через полгорода, на YouTube, бесплатно. Как именно — читайте дальше.

Приветствую всех. Сегодня расскажу вам как я проходил собеседования в Москве на позицию .Net Developer. Усиленно готовился к собеседованиям месяц, целыми днями сидел и смотрел вопросы и пытался отвечать на них, а также читал книжки по С#. В статье привожу интересные задачки и вопросы, которые мне задавали в разных компаниях в Москве. Заранее скажу, что я попал в ту компанию, в которую хотел. Я прошел 4 собеседования в этой компании и меня наконец то взяли! Много статей было прочитано в частности здесь и надеюсь, что эту статью тоже будут читать начинающие Net разработчики и спрашивать все в комментариях.

Кому интересна тема прохождения собеседований, прошу под кат!

Этот пост будет не о том, как «перевести» код с C# на F#: различные парадигмы делают каждый из этих языков лучшим для своего круга задач. Однако вы сможете оценить все достоинства функционального программирования быстрее, если не будете думать о переводе кода из одной парадигмы в другую. Настало время любопытных, пытливых и готовых изучать совершенно новые вещи. Давайте начнем!

Все материалы из серии переводов русскоязычного сообщества F#-разработчиков вы сможете найти по тегу #fsharplangru.

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

— Что, даже на том нечитаемом эзотерическом языке, где есть всего пара команд, которые едва-едва симулируют машину Тьюринга?
— Да, этот язык называется brainfuck. Я знаю brainfuck.

И это был не трюк — мы проверили. Я называл известный мне язык программирования, он тратил пару минут в Интернете на то, чтобы освежить свои знания по нему — и был способен писать на этом языке работающие алгоритмы. Я никак не мог понять этого. Ему, как и мне, было тогда около 18 лет — как он мог в этом возрасте знать все эти языки?


Интерпретатор brainfuck, написанный на brainfuck

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

Сегодня я советую своим студентам «постараться изучить все языки программирования». Подумайте сами — ведь эта идея лучше, чем все вот эти «В этом году я выучу Go! Ой, нет, теперь говорят что в моде Rust — выучу лучше Rust! Или Swift ...». Просто выучите все — не ошибётесь. А эта статья, возможно, вам в этом немного поможет.