Предисловие переводчика

Предлагаю читателям Хабрахабра перевод статьи «The Blockchain Explained to Web Developers, Part 1: The Theory» за авторством Francois Zaninotto. Эту статью я нашел в блоге компании Marmelab. Статья представляет собой отличное введение в технологию блокчейн «с нуля», но может оказаться интересной и для тех, кто уже «в теме». Она касается не только того, как работает блокчейн, но и перспектив его развития, а также с чего начать, если вы хотите создать свой проект, использующий блокчейн.

Объяснение блокчейна для веб-разработчиков, Часть первая: Теория

Блокчейн – это новая популярная технология. Даже если вы не слышали о ней, вы, вероятнее всего, знаете о Bitcoin. Блокчейн — это одна из фундаментальных технологий на которых основан Bitcoin. Эксперты говорят, что блокчейн вызовет революцию схожую с той, которую некогда вызвал Интернет. Но что это на самом деле и как его можно использовать для создания приложений? Эта статья является первой в серии из трех, рассказывающей о феномене Блокчейна. Мы обсудим теорию, покажем фактический код и поделимся своим опытом, основанным на реальном проекте.

В 2014 мы с друзьями решили создать настолько крутые инструменты веб-дизайна, насколько это вообще возможно. Мы создали UI kits, Admin Dashboards, Templates и Plugins.

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



С точки зрения доходов, если не брать во внимание Черную пятницу с ее распродажами (которая помогла нам удвоить прибыль ноября 2016 года), мы выросли примерно до $ 22 000 выручки в месяц. Часть ее уходит на оплату комиссии по партнерской программе, НДС, налога поставщиков и другие траты. В результате на данный момент мы имеем около $17,000 ежемесячной чистой прибыли.
Сегодня я хочу поделиться с вами, как мы создавали свои продукты и как немного раскрутили этот побочный бизнес.

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



Сегодня мы поговорим о React.js и Vue.js. Это – одни из самых популярных JavaScript-библиотек в мире. Взгляните на этот список, посмотрите их репозитории на GitHub. И та, и другая обладают впечатляющими возможностями и служат для создания пользовательских интерфейсов. Работать с ними довольно просто, главное – сразу понять, что к чему, сделать правильный первый шаг. Собственно говоря, этому вот первому шагу в разработке с использованием React и Vue и посвящён данный материал.

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

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

Предлагаю читателям "Хабрахабра" перевод публикации "Painless Merge Conflict Resolution in Git"
из блога blog.wuwon.id.au.

В моей повседневной работе, часто приходится иметь дело со множеством git ветвей (branch). Это могут быть ветви промежуточных релизов, ветви с устаревшим API находящиеся на поддержке для некоторых клиентов, или ветви с экспериментальными свойствами. Лёгкость создания ветвей в модели Git так и соблазняет разработчиков создавать все больше и больше ветвей, и как правило бремя от большого количества ветвей становится очень ощутимым, когда приходится все эти ветви поддерживать и периодически делать слияния (merge) с другими ветвями.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы и интересные материалы из области фронтенда.

Короткая история метода

В короткой публикации [1] под названием “Авторство писателей можно узнать по специальной формуле” сообщалось, что в научном издании «New Journal of Physics», группа шведских физиков из университета Умео под руководством Себастьяна Бернгардсона описала новый метод, который позволяет на основе статистических данных определить автора текста. Исследователи проверяли, как в текстах трех писателей — Томаса Харди, Генри Мелвилла и Дэвида Лоуренса — реализуется так называемый закон Ципфа. Исследователи обнаружили, что частота появления новых слов по мере роста объема текста меняется у разных авторов по-разному, причем эта закономерность не зависит от конкретного текста, а только от автора.

Это сообщение было опубликовано 11.12.2009, а, более двадцати лет тому назад, Джон Чарльз Бейкер [2] ввел единицу для измерения способности автора использовать новые слова (здесь понятие «новые» трактуется как ранее не используемые в данном тексте). Джон доказал, что указанная единица является индивидуальной характеристикой автора.

В периодических изданиях и в сети отсутствует информация о реализации закона Зипфа для определения авторства. Поэтому моя работа является первым научным исследованием в указанной области.

Автор: Эдвард Гори

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

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

Недавно мы в Voximplant улучшали авторизацию в SDK. Посмотрев на результаты, я несколько опечалился, что вместо простого и понятного токена их стало две штуки: access token и refresh token. Которые мало того что надо регулярно обновлять, так еще документировать и объяснять в обучающих материалах. Помня, что в OAuth два токена нужны в основном из-за разных сервисов, на которых они используются (даже вопрос на stackoverflow есть), а у нас такой сервис один, я несколько офигел и пошел на второй этаж вытрясать души из разработчиков. Ответ получился неожиданным. Его нет на stackoverflow. Зато он есть под катом.

Привет, Хабр! Это снова Larian Studios. Нас очень тронул теплый прием и интерес, оказанный жителями Хабра нашей прошлой публикации, и поэтому, не теряя времени, мы решили написать что-нибудь еще.

В этот раз слово возьмет святая святых наших студии — отдел писателей и сценаристов. Так как по-русски они говорят еще не очень хорошо, я послужу переводчиком статьи, написанной специально для Хабра нашей писательницей Charlene Putney alphachar.

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

Так как это текст о писателях — картинок будет мало, а букв много.

В течение следующих 12-24 месяцев — другими словами, между 2018 и 2019 годом – метод приема на работу разработчиков программного обеспечения радикально поменяется.


С 2004 по 2014 я работал в Red Hat — крупнейшей в мире компании по выпуску программного обеспечения с открытым исходным кодом. В первый же день, в июле 2004 года, мой босс Марти Мессер сказал мне: «Вся работа, которую ты будешь выполнять здесь, будет открытой, как на ладони. В будущем тебе не понадобится резюме — люди просто будут получать информацию о тебе в Google».

Всем привет! Меня зовут Олег и сегодня я хочу поделиться своим опытом переезда в Германию.
Я общаюсь до сих пор с многими IT-специалистами из России и очень часто, на мои предложения попробовать себя и поработать в европейской компании с переездом, люди отвечают: «Мой английский не так хорош» или «Как же я буду жить без родственников рядом» или «Мне нужно много денег на переезд». Это всё очень важные и действительно сложные моменты. Но, как я хочу постараться показать на собственном опыте, вполне преодолимые.

Успех культовой серии Penumbra шведской инди-студии Frictional Games привёл к выпуску в 2010 году Amnesia: The Dark Descent. Она стала воплощением «спящего» хита: очевидно нишевая игра завоевала всемирную популярность и сильно повлияла на индустрию. В жанре «хоррор», основы которого были заложены Alone in the Dark и её бессмертными потоками Resident Evil и Silent Hill, стелс-геймплей Amnesia без возможности боя стал странным исключением.

Хотя ведущий дизайнер Frictional Томас Грип (Thomas Grip) назвал Resident Evil своим важнейшим источником вдохновения, Amnesia стала, по моему мнению, явным возвратом к философии Clocktower. В ней акценты сместились с боёв на убегание и скрытность, как в старых играх серии Clocktower. Такие механики практически игнорировались в хоррорах, особенно в играх американских AAA-разработчиков. С помощью Amnesia Frictional напомнила нам, что расстрел врагов не обязательно так же пугающ, как убегание от них. Таким образом авторы возродили ощущение уязвимости в играх survival horror.

В статье описываются работа с PUSH уведомлениями о событиях объектов в браузерах и возможности сервиса VIALATM для работы с треками объектов. Следующие публикации будут посвящены обзорам сервисов IOT.

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

Давайте сделаем такую форму с помощью нашего сервиса MyTaskHelper. Переходим в меню «Формы» → «Создать новую форму» → «Создать форму с нуля». Здесь же вводим необходимое название будущей веб-формы. У нас это «Заказ товара с доставкой» (Рис.1).

В какой-то промежуток времени мне пришлось работать с одной из документоориентированных СУБД — Apache CouchDB, но у меня возникли трудности с поиском документации. В этой статье хочу рассказать о том, как же работать в этой СУБД из JavaScript на примере небольшого приложения «Todo List». Так как статья ориентирована на ApacheCouchDB – я не буду показывать и рассказывать о том, как работает приложение в полной мере.

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

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

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

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

Но этого недостаточно. Нужен прибор которым вы могли-бы непосредственно померять качество воздуха в вашем доме. Что бы Вам было понятно и очевидно чем Вы дышите. Как температура на градуснике.

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

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

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