Всем бородатое ку, товарищи!

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

Здравствуйте, меня зовут… Человек. Число рук равно 2. Число ног равно 2. Группа крови равна 1. Резус равен истине.

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

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

Статья подготовлена для студентов курса «MS SQL Server разработчик»
Хочу поделиться историей из одного из предыдущих проектов, которая иллюстрирует, что Collation нужно выбирать очень вдумчиво. И о том, что бывает, если этот параметр все-таки выбрали неверно, и какие варианты решения проблемы бывают.

Сначала небольшое введение о том, что же такое Collation. В SQL Server параметр Collation указывает серверу, как нужно сортировать и сравнивать строки. Вот, например, строки “Apple” и “apple”. Они разные или нет? Это зависит от указанного Collation. Если с регистром все более менее понятно, то что делать с примером “елка” и “ёлка”? Считать их как одинаковые или как разные? Это все тоже в Collation.

История случилась в проекте, функционал которого очень похож на DropBox или Google Диск. Он предоставляет возможность управлять своими синхронизированными папками и файлами на разных машинах, а также возможность другим пользователям иметь доступ к данной синхронизированной папке.

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

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


В организации, где я работаю, автоматизируют бизнес процессы, и обычно это связано с ведением базы данных. У нас принято работать по канонам, — сначала проводить бизнес анализ, составлять умное ТЗ, писать код, проводить тестирование и много всякой деятельности при дефиците времени. Первичная мотивация, вроде разумная, — “давайте будем разделять обязанности”, “давайте будем делать так, чтобы было безопасно” и тд и тп. Все эти приемы менеджмента с восторгом преподают на различных курсах, обещая много хайпа и охмурянта. Надеюсь, что читатель уже знаком с некоторыми модными словами, которые зачастую ни потрогать, ни налить нельзя. Но вопрос не об них, а о том, как программисту жить с ними.

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

В первой части этого текста мы рассмотрели камеры глубины на основе структурного света и измерения round-trip задержки света, в которых в основном применяется инфракрасная подсветка. Они отлично работают в помещениях на расстояниях от 10 сантиметров до 10 метров, а главное — весьма дешевы. Отсюда массовая волна их текущего применения в смартфонах. Но… Как только мы выходим на улицу, солнце даже сквозь облака засвечивает инфракрасную подсветку и их работа резко ухудшается. 

Как говорит Стив Бланк (по другому поводу, впрочем): «Хотите успеха — выходите из здания». Ниже речь пойдет про камеры глубины, работающие вне помещений. Сегодня эту тему сильно двигают автономные автомобили, но, как мы увидим, не только.


Источник: Innoviz Envisions Mass Produced Self-Driving Cars With Solid State LiDAR

Итак, камеры глубины, т.е. устройства снимающие видео, в каждом пикселе которого расстояние до объекта сцены, работающие при солнечном свете!

Кому интересно — добро пожаловать под кат!

Xkcd — один из самых культовых веб-комиксов, и минималистичный стиль зарисовок будто из учебника механики стал его визитной карточкой. Автор комикса Рэндел Манро признавался, что старательно ищет вдохновение для новых выпусков: он пробует новые программы и игры, работает над математическими задачами, следит за новостями науки и технологий. Если бы он этого не делал, то комикс рассказывал бы о том, как художник сидит дома за компьютером.

Иногда выпуск комикса xkcd — это поверхностная шутка в узкой области знаний. Понять такой юмор сможет специалист или хотя бы слабо знакомый с затрагиваемой областью, а остальные будут лишь недоумевать. Пример такого выпуска — xkcd.com/977 Map Projections 2011 года. Для полного понимания выпуска нужно лишь примерно представлять историю и функцию различных проекций карт мира, иначе комикс останется чёрно-белым рисунком.



Даже внешне однозначные вопросы имеют несколько решений. Форма Земли — это похожий на шар геоид, но для удобства восприятия его лучше развернуть на плоскую карту. Сделать это можно несколькими способами. Каждый из них будет выполнен с различными компромиссами, поскольку искажения формы, углов или длин неизбежны. Какие-то проекции дают больше искажений, другие легче воспринимать, к каким-то мы просто привыкли.

Не все мы смотрим на карту для навигации в открытом море. Часто выбор метода преобразования формы Земли — это не вопрос жизни и смерти, это художественная иллюстрация. В этих случаях проекцию выбирают из устоявшихся вкусов и предпочтений — точно так же, как выбирают одежду или автомобиль. Можно смешно шутить про моду на дорогие кроссовки среди директоров крупных компаний Кремниевой долины или про популярность заниженных автомобилей. Точно так же шуткам поддаются предпочтения картографической проекции, как это и было сделано в Map Projections.

О статье

Этот пост — небольшая заметка, предназначенная для программистов, которым хочется больше узнать о том, как GPU обрабатывает ветвление. Можно считать её введением в эту тему. Рекомендую для начала просмотреть [1], [2] и [8], чтобы получить представление о том, как в общем виде выглядит модель выполнения GPU, потому что мы будем рассматривать только одну отдельную деталь. Для любопытных читателей в конце поста есть все ссылки. Если найдёте ошибки, то свяжитесь со мной.

Содержание

• О статье
• Содержание
• Словарь
• Чем ядро GPU отличается от ядра ЦП?
• Что такое согласованность/расхождение?
• Примеры обработки маски выполнения
  • Выдуманная ISA
  • AMD GCN ISA
  • AVX512
• Как бороться с расхождением?
• Ссылки

Мы с ребятами из Datawire недавно вернулись с потрясающих конференций KubeCon и CloudNativeCon в Барселоне. Мы участвовали в 6 выступлениях на KubeCon, раздали на своем стенде кучу классных (без ложной скромности) футболок, пообщались с десятками людей и посетили крутые выступления. На KubeCon EU было столько всего интересного, что я решил написать пост с ключевыми итогами.

И вот какие выводы я сделал (не в порядке важности):

1. Многоплатформенность и гибридное облако (все еще) популярны.
2. Объединение технологий набирает обороты.
3. Анонс Service Mesh Interface (SMI): следите за новостями.
4. (Туманное?) будущее Istio.
5. Политика как код поднимается по стеку.
6. Облачный DevEx по-прежнему не обходится без проблем.
7. Компании (все еще) на начальных этапах внедрения технологий.
8. Локальный Kubernetes реален (но заковырист).
9. Считайте кластеры стадом.
10. Успех Kubernetes по-прежнему зависит от сообществ.

Привет, %username%.

Я, как обычно, не успокоюсь.

А всему причина пентафторид иода и прошлая статья!

В общем, все мы (надеюсь) помним начало творчества Ридли Скотта и просто потрясающий фильм «Чужой», который я рекомендую, несмотря на то, что он 1979 года. К концу этой статьи я докажу, что фильм не просто крут — он НАУЧЕН!

А для этого мы напряжём память и вспомним концовку: Рипли садится на челнок и внезапно обнаруживает там Чужого.

А теперь будет немного картинок, тёплых воспоминаний и химии.

В процессе перехода от монолитного приложения к микросервисной архитектуре мы сталкиваемся с новыми проблемами.

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

Я долго искал инструмент, который помог бы справиться с такими проблемами (писал об этом на Хабре: 1, 2), но в итоге сделал собственное опенсорсное решение. В статье я рассказываю о преимуществах подхода service mesh и делюсь новым инструментом для его реализации.

Приветствую, хабровчане!

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

В конце марта в Новосибирске отгремел юбилейный 10-ый CodeFest. Как и, наверное, любая конференция, CodeFestX оставил участникам кучу разных впечатлений от «ноги моей тут больше не будет» до «как купить пожизненную подписку?». То, как это было я описывать не буду, отзывы уже есть и, думаю, еще появятся. Хочу поделиться историей того, как мы запустили альтернативную версию для расписания Codefest (смотреть лучше с мобилки): от идеи до получившегося результата.

В прошлом году купил оборудование для аварийного перекрытия кранов при обнаружении протечки от «Аквасторож». Долго не мог его поставить. Была идея интегрировать его в Z-Wave сеть и получить аналог gidrolock, но работающий на батарейках. Наконец-то руки дошли…

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

Одна из таких помех – мы учим его не тем местом. Речь не о частях тела, а о зонах мозга. Есть в префронтальной коре головного мозга зоны Вернике и Брока, которые связаны с восприятием и продуцированием речи… У взрослых они отвечают за прием акустических сигналов, за саму возможность речевой деятельности.

А ребятишки лет пяти-семи усваивают другой язык с удивляющей легкостью! Это при том, что мозг их по-настоящему незрел. Формирование коры заканчивается годам к двенадцати-пятнадцати – и тогда человек обретает способность к законченным логическим построениям, «в ум входит», как говорится… В эту пору зоны Верника и Брока созревают и начинают за речевую деятельность человека отвечать. А что же происходит до созревания коры, которую мы усиленно нагружаем при изучении иностранного языка?

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

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

Три года назад мы объявили о выходе CUBA 6. Та версия стала революционной: вместо закрытой проприетарной лицензии мы стали распространять фреймворк свободно, по лицензии Apache 2.0. В то время мы не могли даже и близко представить, насколько это отразится на развитии фреймворка в долгосрочной перспективе. Сообщество CUBA стало расти в геометрической прогрессии, и мы столкнулись со всеми возможными (а иногда и невозможными) способами применения фреймворка. Сейчас мы представляем вашему вниманию CUBA 7. Надеемся, что эта версия сделает разработку ещё проще и приятнее для всех членов сообщества: от начинающих, которые только познакомились с CUBA и Java, до опытных разработчиков, за плечами которых не один завершенный проект уровня большой компании.

Инфраструктура виртуальных рабочих столов (VDI), несомненно, удобна для крупных предприятий, располагающих сотнями и тысячами физических компьютеров. Однако насколько практично это решение для малых и средних предприятий? Получит ли предприятие со 100, 50 или 15 компьютерами существенные преимущества, внедрив технологию виртуализации?

В открытом доступе была обнаружена база данных MongoDB, не требующая аутентификации, в которой находилась информация московских станций скорой медицинской помощи (ССМП).

К сожалению, это не единственная проблема: во-первых, на этот раз данные действительно утекли, а во-вторых – вся чувствительная информация хранилась на сервере, находящемся в Германии (хотелось бы поинтересоваться – не нарушает ли это никакой закон или ведомственные инструкции?).

Низкий поклон Хабранароду!

Предисловие

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

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

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…