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

Посмотрев на реализации представленные в интернете я ужаснулась. В теле страницы куча текста! С такой разметкой же невозможно работать. А если надо поменять информацию? Это надо лезть в html, искать нужное, и менять в нескольких местах. Короче ужас! И я подумала что хорошо бы использовать базу данных, но это же обычная страница, и разворачивать ради нее целый сервер? и базу? как то перебор! Работая с Angular2 я подумала что было бы классно с его помощью создать страницу, но он очень тяжелый, и не подходит… И тут я вспомнила о его аналоге Vue.js. Легкая библиотека, для создания приложений. Я подумала: "А почему бы не создать сайт с помощью vue и добавить имитацию базы?".

Обдумав все за и против, посмотрев на другие подходы, мне захотелось внести немного "красоты" в html верстку.

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

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

Пpивeтcтвyю вcex!

Ceгoдняшняя небольшая cтaтья, впpoчeм, кaк вceгдa, кoнeчнo жe, o зaмeчaтeльнoм и пpocтoм, кaк тpи кoпeйки, фpeймвopкe для кpoccплaтфopмeннoй paзpaбoтки Kivy.

B дaннoм мaтepиaлe бyдyт paзвeяны мифы o тoм, чтo Kivy нe гoдитcя для paзpaбoтки cлoжныx пpилoжeний, бyдyт oпpoвepгнyты пpeдвзятыe мнения, кoтopыe пpeдcтaвляют paзpaбoтчикaм и зaкaзчикaм Kivy, кaк мaлo пoдxoдящий и кpивoй инcтpyмeнт для cepьeзнoй paбoты и coвceм нeгoдным для production.

Ceгoдняшняя cтaтья бoльнo yдapит пo кocтылям других фреймворков, зacтaвит их пoшaтнyтьcя, ocoзнaть, чтo oни yжe oтнюдь нe eдинcтвeнные и пoдвинyтьcя нaзaд в peйтингe кpoccплaтфopмeннoй paзpaбoтки, cпpaвeдливo ycтyпaя мecтo Kivy, как более быстрому в плане разработки, не менее надежному и более выгодному инструменту!

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

(Update: заменил картинку на более нейтральную)

Коллега упомянул в беседе принцип "Convention over configuration", и я подумал, блин, наверно это что-то крутое, нужно изучить, почитать статьи, а то отстану от жизни.

Каково было моё удивление, что вcё обьяснение помещается в одной фразе "Используй дефолты, которые можно при желании переопределять".

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

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

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

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

В компании, где я работаю — большинство сервисов запускаются и работают в docker-контейнерах.

В связи с этим, у моих коллег-новичков-в-докере часто возникает вопрос — а как писать код и запускать его в этом чёртовом контейнере???

Для человека, написавшего около сотни docker-образов и запускающего их несколько раз в день — такой вопрос уже не стоит, но когда я разбирался с докером в давние времена — мысль "Как же писать код в докере? Это же сверхнеудобно!" долго была актуальной.

В статье я опишу свои практики работы с образами docker, которые позволяют писать код "как у себя в home", и даже лучше.

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

В многих проектах для esp8266 я использую TFT экран с тачскрином. В зависимости, от проекта интерфейс может быть простым, например, текстовая консоль, выводящая лог работы приложения или просто график изменения входного сигнала. А в некоторых — сложный GUI, с несколькими экранами, графическими кнопками, строками ввода текста и даже виртуальной клавиатурой.

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

Видео-тизер:

Итак, приступим

На днях мне пришла в голову мысль, что было бы здорово написать простой Redis-подобный сервер баз данных. Хотя у меня значительный опыт работы с приложениями WSGI, сервер базы данных представил новый вызов и оказался хорошей практикой в процессе обучения работе с сокетами в Python. В этой статье расскажу, что я узнал в процессе исследования.

• Обзор различных типов Placeholder’ов
• Placeholder на основе SVG (контуры, фигуры и силуэты)
• Автоматизация процесса.

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

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

Напомню, что основным элементом представленного способа задания стилей является обобщенное замыкание:

typealias Decoration<T> = (T) -> Void

Использовать данное замыкание для придания свойств UIView можно следующим образом:

О том, как коммитить изменения в Docker образ

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

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

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