Всем привет, я снова выхожу на связь и посмотрите с чем! На фото — очень редкий (на 1989г. было выпущено 56 штук) сканирующий электронный микроскоп производства компании TESLA, выставленный в техническом музее г. Брно. Сверхвысоковакуумная колонна, катод с холодной полевой эмиссией позволили достичь гарантированного разрешения в 5нм и увеличения 500000x.



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

Большая часть статей об A/B-тестах посвящена веб-разработке, и несмотря на актуальность этого инструмента и для других платформ, мобильная разработка несправедливо остаётся в стороне. Мы попытаемся эту несправедливость устранить, описав основные шаги и раскрыв особенности реализации и проведения A/B-тестов на мобильных платформах.

Предыстория

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


Так в чем же, с моей точки зрения, проблема?

В предстоящий релиз Spring Data под кодовым именем Lovelace мы собираемся включить новый модуль: Spring Data JDBC.

Идея Spring Data JDBC заключается в том, чтобы предоставить доступ к реляционным базам данных без использования всей сложности JPA.

Научитесь выявлять их. Выработайте привычки избегать их.

Цель этой статьи не загнобить новичков за типичные ошибки, а научить выявлять их и избегать. Порядок перечисления – случайный.

От переводчика

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

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

Предисловие

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

Disclaimer: Всем можно, ну а я чем хуже?!

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

Попробуем разобраться в этих принципах на пальцах, без примеров кода и СМС.

«Проще, чем кажется» — бизнес-роман о том, на что еще способны программисты.

1

— Слушай, Сергей, ты меня достал уже. Просто назови срок, когда сделаешь отчет.

— Я не хочу делать отчет в таком виде, это неправильно. Не отчет, а глупость какая-то. Галя, ты сама разве не видишь?

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

— Даже если задача — полный бред? Даже если отчет никому не нужен, и никто не будет на него смотреть?

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

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

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

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

Для трассировки лучей (ray tracing) настали удивительные времена. Компания NVIDIA реализует ускоренное с помощью ИИ шумоподавление, Microsoft объявляет о нативной поддержке в DirectX 12, а Питер Ширли продаёт свои книги по свободной цене (pay what you want). Похоже, что трассировка лучей наконец получила шанс быть принятой при дворе. Возможно, говорить о начале революции ещё слишком рано, но уже определённо стоит начать изучать и накапливать знания в этой области.

В этой статье мы напишем с нуля в Unity очень простой трассировщик лучей с помощью compute shaders. Скрипты мы будем писать на C#, а шейдеры — на HLSL. Весь код выложен на Bitbucket.

В результате у нас получится отрендерить нечто подобное:

Недавно мы выпустили первую версию нового фреймворка по глубокому обучению DeepJava (DJ) 0.01.

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

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

Это вторая из серии статей об инструментах и методах фоновой работы в Android. Ранее уже были рассмотрены AsyncTask, в следующих выпусках — ThreadPools с EventBus, RxJava 2 и корутины в Kotlin.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Discover tools for Android data migration and improve your app retention» авторов Sean McQuillan и Prateek Tandon.

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

Многим известна шуточная зависимость между способностью к программированию и количеством выпитого. Согласно теории, существует определённая доза, открывающая сверхчеловеческие способности к кодингу (согласно эмпирическим данным — около 2 бутылок пива). Однако задавались ли Вы вопросом, какова доля шутки в этой шутке? Немного алкотеории и алкопрактики с блекджеком и шл... цифрами и графиками на дне стакана под катом.

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

Если вы интересуетесь разработкой AR приложения на андроиде, в частности хотите написать свои «Маски», или любое другое AR приложение, то вам сюда. Здесь я вам дам краткий экскурс, как это можно сделать, не считаю, что я предлагаю самый лучший вариант, может быть проще воспользоваться уже готовыми фреймворками, но он по крайней мере рабочий и не сложен в реализации. Вообще в данном случае, как мне кажется не надо использовать какую-либо дополнительную обвеску, в виде библиотек или фреймверков или чего-либо еще, т.к. она только загромождает все сущее, а достаточно воспользоваться стандартными средствами. Здесь я покажу как работать с камерой, как можно обработать изображение, и как наложить эффекты, предполагаю, что читатель уже умеет создавать “Hello world” на андроиде. Все это под катом.

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

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

Processing — это простенькая среда разработки с языком Java с ограниченным числом классов. Здесь есть переменные, циклы, объекты. В первую очередь Processing расчитан на работу с графикой, анимацией, вычислениями. То, что так нравится детям. Всё наглядно и красиво.
Если у пользователя появится желание перейти на новый уровень и начать использовать полноценный язык Java, то все наработки не пропадут даром. Большая часть кода не потребует переработки и можно свободно копировать больше участки кода.

Это реальная история. События, о которых рассказывается в посте, произошли в США в 2015-2016 годах. Имена персонажей были изменены, однако всё остальное описано так, как было на самом деле.

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

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

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