Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.

• Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
• Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
• Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
• Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.

Жил на свете такой человек – Стивен Кови. Однажды он решил написать книгу о личной эффективности. Теперь эту книгу знают все, она называется «Семь навыков высокоэффективных людей». Она считается классикой, постоянно переиздается во всех мыслимых странах мира, за годы существования продано несколько десятков миллионов экземпляров. Сам Стивен Кови настолько разобрался в личной эффективности, что его личными консультациями не преминули воспользоваться несколько президентов, в т.ч. США.

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

Но я не про книгу хочу поговорить, а про неожиданное открытие, которое сделал Стивен Кови, когда ее писал. Он это явление назвал «социальный аспирин».

Продолжу тему мотивации, начатую в “Прогулке по заводу желаний”.

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

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

Перечисление разных эмоций можно встретить в разных хабро-хабах, например: Управление персоналом, Научно-популярное, Машинное обучение, Обработка изображений, Тестирование IT-систем, Разработка веб-сайтов.

Упоминание отдельных эмоций можно встретить практически в любом живом хабе. Эмоции важны, не так ли? Кажется, что важная тема хорошо изучена.

Разрешите усомниться.

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



Борьба популяций цифровой плесени под воздействие испепеляющего солнца.

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

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

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

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

Ближе к теме — почему иногда трудно заставить себя работать? Заглядываем в интернет, и сразу получаем решения — надо закрыть соцсети, разбить задачу на мелкие шаги и хвалить себя.

Или еще проще — проблемы нет, у вас воля слабая, отговорки ищете, возьми и сделай (just do it).

Позвольте усложнить.

Как выживать в турбулентной корпоративной среде. Только для теоретического изучения.

Не знаю, как вам, а мне приходилось работать в достаточно турбулентной корпоративной среде, и не один раз.

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

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

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

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

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

Юрий Андрейкович, Senior Product Manager в Wrike, рассказал на конференции ProductSense в Минске, когда и зачем надо удалять фичи из продукта.



Я работаю в Wrike — это сервис для совместной работы и управления проектами. В Wrike более миллиона пользователей, но наши прямые клиенты — это компании, которые платят за сотрудников. Таких примерно 17 тысяч.

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

В рамках проходящей в данный момент выставки CES 2019 подразделение IBM Research провело анонс первой в мире квантовой системы, пригодной для коммерческого применения.

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

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

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

Они думают только о сегодняшнем дне. Возможно, виновата жесткая привязка к одному вендору, который разрабатывает и фреймворк, и прикладные решения. Никто же в здравом уме не будет в 21 веке строить долгосрочный бизнес, завязанный на один язык программирования, одну среду разработки, один рынок? А вот ковать железо, пока горячо — пожалуйста. Когда остынет, тогда и можно будет задуматься о чем-то серьезном.

Но мне, почему-то, кажется, что не все потеряно. Можно сделать лучше.

Еще со времен обучения в университете я использовал LaTeX для оформления лабораторных и курсовых работ. Познакомился впервые с LaTeX на Coursera, на курсе "Документы и презентации в LaTeX".

В этой заметке я расскажу, как я писал диплом с помощью LaTeX и почему я использовал GitHub, Docker и TravisCI.

Здравствуйте, коллеги.

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

Части 1-3: сетка, цвета и высоты ячеек

Части 4-7: неровности, реки и дороги

Части 8-11: вода, объекты рельефа и крепостные стены

Части 12-15: сохранение и загрузка, текстуры, расстояния

Части 16-19: поиск пути, отряды игрока, анимации

Части 20-23: туман войны, исследование карты, процедурная генерация

Части 24-27: круговорот воды, эрозия, биомы, цилиндрическая карта

Часть 12: сохранение и загрузка

• Отслеживаем тип рельефа вместо цвета.
• Создаём файл.
• Записываем данные в файл, а затем считываем его.
• Сериализуем данные ячеек.
• Уменьшаем размер файла.

Мы уже умеем создавать достаточно интересные карты. Теперь нужно научиться их сохранять.

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

Достаточно частая проблема в программировании — то, что разработчики сфокусированы только на функциональных возможностях того или иного компонента, при этом совершенно не учитывают очень важную нефункциональную составляющую, которая может влиять на производительность, масштабируемость, легкость восстановления в случае сбоев, безопасность и т.д. Например, тот же HttpClient — вроде бы и элементарный компонент, но есть несколько вопросов: сколько он создает параллельных соединений к серверу, как долго они живут, как он себя поведет, если DNS имя, к которому обращался ранее, будет переключено на другой IP адрес? Попробуем ответить на эти вопросы в статье.

На Хабре уже долгое время публикуется совместный перевод (у которого ещё есть отдельный сайт авторства MagisterLudi) замечательной книги Ричарда Хэмминга "The Art of Doing Science and Engineering". Я долгое время хотел её прочитать в оригинале. Да не просто прочитать, а составить насколько возможно краткую выжимку основных идей каждой главы. И вот недавно мне удалось это сделать.

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

Из-за достаточно большого количества материала и его "плотной" подачи данная статья всё равно получилась достаточно объёмной. Поэтому предлагаю её TL;DR.

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Overview and Comparison of Gate Level Quantum Software Platforms" автора Ryan LaRose.

Квантовые компьютеры доступны для использования в облачной инфраструктуре, но в тоже время недавний бурный рост квантовых программных платформ может быть ошеломляющим для тех, кто будет принимать решение, что использовать. В этой статье предлагается текущая картина быстро развивающегося ландшафта квантовых вычислений путем сравнения четырех программных платформ — Forest (pyQuil), QISKit, ProjectQ и комплекта Quantum Development Kit, — которые позволяют исследователям использовать реальные и моделируемые квантовые устройства. Этот анализ охватывает требования и установку, синтаксис языка на примере программ, поддержку на уровне библиотек и возможности квантового симулятора для каждой платформы. Для платформ с поддержкой квантового компьютера мы сравним аппаратные средства, квантовые ассемблерные языки и квантовые компиляторы. В заключение мы рассмотрим особенности каждого из них и кратко упомянем другие пакеты программного обеспечения для квантовых вычислений.

При поиске этого словосочетания англоязычный Гугл выдает 104 000 000 результатов. По статистике, боязнь публичных выступлений входит в топ-5 человеческих страхов. Каждый выступавший признается в интервью, что хотя бы раз испытывал страх перед выступлением.

У команды Microsoft Quantum Team хорошие новости для любителей квантовых вычислений и программистов, желающих бросить себе вызов. Мы рады сообщить о проведении летнего конкурса Microsoft по программированию на Q# — Microsoft Q# Coding Contest — Summer 2018! Приняв участие в нем, вы сможете отточить свои навыки в области квантового программирования, решая задачи различной сложности с помощью языка квантового программирования Q#. Победители получат футболки Microsoft Quantum!

У программы есть цель, о которой иногда забывают

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

Кажется, программисты забыли о предназначении программного обеспечения — решать проблемы реального мира.

50 лет назад, в 1968 году, прошла Рабочая конференция по инжинирингу ПО, организованная Комитетом по науке НАТО. Тогда стали замечать, что программное обеспечение становится фундаментальной частью общества. И одновременно его становится труднее понять. После этой конференции программирование начало превращаться в настоящую индустрию. Оно начало уходить из-под контроля бизнеса.