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

В статье я приведу цифры и расчеты. А еще свой вариант решения проблемы и устройство, собранное для этого. Кому интересно, прошу под кат…

Часто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.



Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.

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

Git Merge

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

Термин «современный C++» часто используется как синоним выражения «код, использующий новый стандарт C++». Здесь «новый» может означать что угодно от C++11 до C++17, или даже то, что уже сейчас доступно из C++20. Я думаю, что современный C++ — это нечто большее, не ограничивающееся добавлением флага -std=c++17.

Привет, Хабр!

Сегодня мы предлагаем вам сравнительно краткую, но при этом толковую и информативную статью об устройстве и вариантах применения Apache Kafka. Рассчитываем перевести и выпустить книгу Нии Нархид (Neha Narkhede) et. al до конца лета.


Приятного чтения!

Одной из самых заметных новшеств современного JavaScript стало появление стрелочных функций (arrow function), которые иногда называют «толстыми» стрелочными функциями (fat arrow function). При объявлении таких функций используют особую комбинацию символов — =>.

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

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

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

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

Предисловие

Для начала представлюсь, меня зовут Эдик, я Full Stack Web Developer. Основные направления Laravel & React.js, Vue.js. Изучаю GoLang и Swift.

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

Чтобы структурировать данные информация будет представлена в виде серии статей разбитых по главам.

Я пишу эти нотатки для себя и решил поделится ими со всем миром. Так что не будьте суровы. И так, поехали!

Глава 1. Добро пожаловать в React

React — популярная библиотека, используемая для создания пользовательских интерфейсов. Она была создана в Facebook чтобы решить ряд проблем, связанных с крупномаштабными сайтами.

Почему формальное определение цвета то ли есть, то ли нет, и связано ли это с тем, что его дал тот самый Шрёдингер? Что имел в виду Вейнберг, когда назвал свою революционную статью «Геометрия цветов»? Почему у цветового треугольника два угла, хотя интуитивно кажется, что должен быть один? Почему обычный детский рисунок показывает, что у автора всё в порядке с цветовосприятием, и зачем художник-академист всю жизнь учится его отключать? Почему в цветовом пространстве находятся кластеры, но они не находятся? Почему любая женщина знает о явлении метамерии окрасок, а ученые всё время забывают? Сколько должно быть цветовых каналов у хорошего фотоаппарата? А у монитора? А почему ответ разный? А красок у принтера?

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



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

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

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

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

После выхода mysql 5.6 с его GTID (global transaction identifier) репликация в mysql перестала быть кошмарным сном сисадмина и стала вполне рабочим инструментом. В инете есть некоторое количество информации по этому поводу, но вся она довольно разрозненная и не всегда доступна для понимания. По этому я решил сделать небольшую инструкцию-выжимку, больше для себя, но может и еще кому пригодится.

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

Что такое массивы на уровне PHP?

На уровне PHP, массив — это упорядоченный список скрещенный с мэпом. Грубо говоря, PHP смешивает эти два понятия, в итоге получается, с одной стороны, очень гибкая структура данных, с другой стороны, возможно, не самая оптимальная, точнее, как выразился Anthony Ferrara:

PHP arrays are a great one-size-fits-all data structure. But like all one-size-fits-all <anything>, jack-of-all-trades usually means master of none.

Ссылка на письмо

(на картине изображен HashTable с Bucket-ами, В. Васнецов)

Наверняка все знакомы с таким понятием как test-driven development(TDD). Наряду с ним также существует такое понятие, как data-driven testing(DDT, не в обиду Шевчуку) — техника написания тестов, при которой данные для тестов хранятся отдельно от самих тестов. Они могут храниться в базе данных, файле, генерироваться во время исполнения теста. Это очень удобно, так как один и тот же функционал тестируется на различных наборах данных, при этом добавление, удаление или изменение этих данных максимально упрощено.

В предыдущей статье я рассмотрел возможности JUnit-а. Там примерами такого рода подхода могут служить запускалки Parameterized и Theories, в обоих случаях один тест-класс может содержать только один такой параметризированный тест(в случае Parameterized несколько, но все они будут использовать одни и те же данные).

В этой статье я заострю внимание на тестовом фреймворке TestNG. Многие уже слышали это название, и перейдя на него, вряд ли желают вернуться к JUnit-у(хотя это только предположение).

«Начало — более чем половина всего».

Это очень древний GTD-принцип: возраст его, вероятно, исчисляется тысячелетиями. (Например, Викицитатник в настоящее время приписывает его Аристотелю, хотя и без подтверждающего указания на первоисточник.) Суть его в том, что с чистого листа начинать какой-либо проект бывает очень трудно (и даже приходится заставлять себя); а вот если есть несколько простых начальных шагов, выполнение которых приводит к появлению частично готового проекта, то продолжить работу над ним «по инерции» становится куда проще — так просто, как если бы проект этот ужé был не только начат, но и готов даже более, чем наполовину. А кроме того, когда заранее хорошо знаешь, какими должны быть начальные шаги, то тогда трудно бывает допустить ошибку, совершая их.

Мне довелось сочинить более десятка модулей для Node.js с открытым исходным кодом и опубликовать их в качестве пакетов npm. Чем больше модулей я делал, тем сильнее понимал (в том числе путём проб и ошибок), что начальные шаги для их создания могут быть одинаковыми и даже могут совершаться в одном и том же порядке. Сегодня я публикую этот порядок в надежде на то, что он станет подспорьем в работе программистов, сочиняющих свой код на языке JavaScript для движка Node.

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

Я очень люблю статические типы, поэтому TypeScript стал незаменимым помощником при работе с NodeJS или браузерным JS.

По долгу службы приходится иметь очень много дел с JSON, и здесь система типов TypeScript не помогает ничем, даже мешает, ведь компилятор сообщает об отсутствии ошибок, JSON.parse возвращает тип Any. Кроме того, TypeScript не поддерживает рефлексию, ввиду специфики работы, а значит, нет возможности проверить тип, основываясь на уже существующем коде. Также, до последнего времени, средств для мета-программирования не было вовсе.

Зачастую проверка корректности пришедшего JSON-объекта оборачивается громадным кодом в конструкторах классов, либо такими же конфигурационными файлами. Но, наконец-то, в TypeScript 1.5 появились декораторы.

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

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

• разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
• UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.

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

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

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

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.

Возникла задача собрать карту мира. Причем именно собрать из множества стран, стран-регионов, потому как страны должны быть кликабельны. Да проще некуда, скажете вы, всего-то и надо запилить целую карту да развесить по странам полигон-коллайдеры, пффф… Но нет, подразумевается, что страна должна будет изменять цвет на красный или черный и при клике будет выделяться белым. Кроме того, со временем на стране должны появляться красные поинты (да-да… я знаю, о чем вы подумали). Этих поинтов должно быть достаточно много на карте.

Было принято решение собрать карту при помощью Canvas. Удобная штука, экономит массу времени. Но не в этот раз.

Статья 1. Почему я не преподаю SOLID

Если вы разговариваете с кем-то, кому небезразлично качество кода, уже достаточно скоро в разговоре всплывёт SOLID — аббревиатура, помогающая разработчикам запомнить пять важных принципов объектно-ориентированного программирования:

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

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

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

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

На факультете помимо занятий для студентов есть специальные семинары, на которые могут приходить все желающие. Они проходят в рамках Коллоквиума факультета компьютерных наук ВШЭ. Семинары проводят учёные не только из Вышки, но из других вузов и научных центров — МГУ, МФТИ, Математического института и института системного анализа РАН, MIT, Microsoft Research, Школы анализа данных Яндекса. Прийти их послушать может не только студент или сотрудник ФКН, но и любой желающий. С сегодняшнего дня мы начинам публиковать записи избранных выступлений.



Первый семинар, который мы выбрали, проводил известный российский биоинформатик Михаил Гельфанд. Из него вы узнаете об основных информационные процессах, протекающих в клетке при реализации геномной программы. Как говорил сам Михаил Сергеевич, доклад задумывался как «crash course по молекулярной биологии для тех коллег, которые хотят понимать, чем занимаются биологи и про что разговаривают биоинформатики».

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



С тех пор большинство настольных браузеров следуют тенденции и используют фавикон тем или иным способом. Это очень просто, не так ли? Создать маленькую картинку и добавить в любой интернет-проект, чтобы сделать его «завершённым». Ничего сложного.