Привет, Хабр! Представляю перевод статьи, Let me help you to understand and choose a state management solution for your app, которая попалась мне и заинтересовала в процессе изучения азов управления состоянием во Flutter. Буду рад услышать любую критику касательно данного перевода. В обратных кавычках (``) будут написаны мои личные мысли и пояснения.

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

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

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

Так что в списке «Самые неразвивающиеся компаниии» остаются только франчайзи 1С. Там работает куча прекрасных людей, но то ли среда такая, то ли место проклятое — с ними что-то не так.

Они думают только о сегодняшнем дне. Возможно, виновата жесткая привязка к одному вендору, который разрабатывает и фреймворк, и прикладные решения. Никто же в здравом уме не будет в 21 веке строить долгосрочный бизнес, завязанный на один язык программирования, одну среду разработки, один рынок? А вот ковать железо, пока горячо — пожалуйста. Когда остынет, тогда и можно будет задуматься о чем-то серьезном.

Но мне, почему-то, кажется, что не все потеряно. Можно сделать лучше.

Разработчик, с гуманитарным высшим, средним английским (сильный акцент и неправильное произношение), 15 годами опыта в десятке проектов, обремененный семьей – вдруг решил найти работу в Западной Европе.

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

Предупреждение: возможно уменьшение удовольствия от игр и фильмов, так как появится осознание и понимание как они устроены.

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

Далее, под словом «фан», имеется ввиду положительные эмоции.

Поиск в интернете точного ответа не дал. Кто-то пишет, что игрокам нравится делать то, что в реальном мире они не могут. Другие пишут, что важен сюжет. По таким описаниям хорошую игру не сделать.

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

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

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

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

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

Это была славная охота.

Моя жизнь была посвящена ИТ-сфере. Я был инженером, создававшим интересные продукты для больших промышленных компаний. Моей географией была вся Россия, я вживую видел цеха КАМАЗа, ВАЗа и других автогигантов. Но всему в нашей судьбе настаёт предел, и я выгорел. О причинах расскажу как-нибудь в другой раз. Главное, что я, опытный разработчик и техник, ушёл на вольные хлеба и, поскольку у меня появилась семья, решил сделать бизнес — свой магазин товаров для детей, по особым принципам. В общем, как многие из программеров, сделать то, чего не достаёт мне среди предложений на рынке. И знаете, что? Я выяснил, что найти простейших, базовых, нужных профессионалов-подрядчиков очень сложно. Миллион фрилансеров и фирм, а выхлоп… Это был квест, и о нём я должен поведать миру. Не ходите по моим граблям.


Это самое лучшее, что описало моё состояние

Сегодня мы публикуем перевод материала, автор которого хочет рассказать о самых популярных в наши дни фреймворках для Node.js. В этот список входят Sails.js, Hapi.js, NestJS, LoopBack, Derby.js, Mean.io и Total.js.

Автор статьи: Константин Сафонов

Не хочу читать эту техническую болтовню. Просто повали уже мой браузер.

Что такое CraSSh

CraSSh — это кроссбраузерная чисто декларативная DoS-атака, основанная на плохой обработке вложенных CSS-функций var() и calc() в современных браузерах.

CraSSh действует во всех основных браузерах на десктопах и мобильных устройствах:

• На движке WebKit/Blink — Chrome, Opera, Safari, даже Samsung Internet на смарт-телевизорах и холодильниках.
  
  • Android WebView, iOS UIWebView также затронуты, то есть можно обвалить любое приложение со встроенным браузером.
• На движке Gecko — Firefox и его форки, такие как Tor Browser.
  
  • Servo не запустился ни на одной из моих машин, поэтому я его не протестировал.
• На движке EdgeHTML — Edge в Windows, WebView в приложениях UWP (их вообще кто-нибудь использует?)

Браузер IE не затронут, поскольку он не поддерживает функции, на которых основана атака, но у его пользователей немало своих проблем (вероятно, этот браузер можно порушить другими способами — прим. пер.).

В данной статье я хочу рассказать о небольшом и забавном проекте выходного дня по передаче файлов через анимированные QR коды. Проект написан на Go, с использованием Gomobile и Gopherjs – последний для веб-приложения для автоматического замера скорости передачи данных. Если вам интересна идея передачи данных через визуальные коды, разработка веб-приложений не на JS или настоящая кроссплатформенность Go — велкам под кат.

В последнее время в мобильном сообществе часто можно услышать про Flutter, React Native. Мне стало интересно понять профит от этих штук. И насколько они реально изменят жизнь при разработке приложений. В итоге было создано 4 (одинаковых с точки зрения выполняемых функции) приложения: нативное Android, нативное iOS, Flutter, React Native. В этой статье я описал то, что вынес из своего опыта и как реализуются схожие элементы приложений в рассматриваемых решениях.

В предыдущей статье я подробно рассказал о нашем опыте создания веб-сервиса/мобильного приложения для ведения личного дневника. Актуальная версия приложения (минимальная работоспособная версия уже выложена в Google Play) разрабатывается на React Native, и вот на нем мы и остановимся подробно сегодня.

Рассказываем о собственном опыте работы с фреймворком, способах расширения функционала, «подводных камнях» (куда ж без них!) и как мы их обошли.

О фреймворке в целом

Немного о виновнике торжества — React Native. Он все-таки хорош!

Для тех, кто в достаточной степени знает JavaScript и тем более NodeJS — он очень хорош. Если же есть опыт с React, ну или хотя бы есть понимание ее идеи, механизма — он просто великолепен!

Главное, что на выходе получается действительно нативное приложение. Расширения и плагины покрывают практически 99% типовых задач. Оставшийся процент при острой необходимости можно дописать на родных языках (java, object-c) и подключить к React Native приложению.

Но хватит про плюсы, от них толку ноль, хоть список и будет внушительным. Все плюшки и вкусности бессмысленны, если приложение не запускается, а это первое чем нас «порадовал» React Native.

Сначала ему не понравилась версия NodeJS. Потом версия npm. Потом версия Android SDK, потом версия Android tools, потом… Писать про то, как все проблемы решились, смысла нет, ибо с того момента все вышеперечисленное ПО обновило свои версии и инструкции будут неактуальны.

Просто знайте: узкое место React Native — среда сборки. Будьте готовы к штудированию google, чтению форумов и stackoverflow. На развертывание в итоге потратили: Ubuntu — 3 дня, Win10 — 2 дня. Как ни странно, на «винде» все оказалось проще, ну, или просто на ubuntu «шишек набили» и уже понимали, что и куда подсовывать.

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

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

Что за игра-то? И кто “мы”?

Мы — это команда из трех человек (GRaAL, A333, icxon), волею судеб названная Volcanic Giraffe без какого либо умысла. Работали долгое время вместе, несколько раз втроем участвовали в Ludum Dare (соревнования по написанию игр за выходные), и однажды решившие довести до релиза одну из наших поделок под названием Protolife.

Если коротко: это необычная tower defense, где надо бегать героем-курсором и выстраивать оборону из блоков против постоянно растущей красной биомассы.

Одна из проблем, которая возникает перед WEB-ресурсами имеющими персональные кабинеты — атака перебором. Да, простой перебор всех вариантов пароля для конкретной учетки. Тупо? Возможно, но такая атака может сильно нагрузить ресурс. К тому же, если контроля сложности пароля пользователя при регистрации нет, она может оказаться еще и успешной.

Чаще всего, вопрос решается относительно просто. Если пользователь ввел несколько раз неправильно пароль, его учетка блокируется на какое-то время. Альтернативное решение — выводить капчу. Сразу, или после нескольких неудачных попыток. Ну, и не забудем про 2F авторизацию, которая почти неуязвима. Казалось бы — профит! Но, не все так радужно…

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

У меня есть довольно большой опыт — в течение последних семи лет я работал только в этом жанре (Cogmind, Cogmind 7DRL, POLYBOT-7, REXPaint, X@COM), и в течение последних пяти эта работа была моей основной. К тому же, все эти годы я помогал превращению r/RoguelikeDev в крупнейшее сетевое сообщество разработчиков roguelike.

От переводчика:
Я не являюсь ни профессиональным программистом ни профессиональным переводчиком, но появление описанного в статье инструмента от создателя популярной библиотеки D3.js произвело на меня сильное впечатление.

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

Знакомьтесь, d3.express, интегрированная исследовательская среда.
(с 31 января 2018г d3.express зовется Observable и живет на beta.observablehq.com)

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

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

Предназначение инструмента визуализации — построение визуализаций. Но в чем же цель визуализации? Слово Бену Шнейдерману(Per Ben Shneiderman):

«Результат визуализации — это

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



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

Мой сын заинтересовался программированием на Python, и у меня появился вопрос – есть ли сегодня возможность купить книгу для ребёнка в качестве самоучителя? Самоучители для взрослых детям не подходят – мотивации продираться самостоятельно через учебники программирования и у взрослых не всегда хватает, а у ребёнка скучное «академическое» изложение вообще может убить весь интерес к предмету на пятой странице.

К счастью, на момент написания статьи (конец 2018 года) выбор оказался весьма широк – есть как переводные, так и отечественные книги, нацеленные на детскую и подростковую аудиторию. В ходе поиска, отсеяв книги по Python 2, я смог найти 10 свежих книг по Python 3 для детей, изучил каждую их них вживую в офлайн-магазинах, и результатами своих изысканий хочу поделиться с вами в статье под катом.

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

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

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

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

Сэр Тим Бернерс-Ли на Campus Party 2008, фото Jonan Basterra

Сэр Тим Бернерс-Ли, создатель Всемирной паутины и директор консорциума W3C, уверен, что развитие веба достигло критической точки, максимально отклонилось от изначальной концепции. Изначально он задумывался как децентрализованная сеть, где первый браузер одновременно был и редактором документов. Идея состояла в том, что каждый пользователь не только сможет просматривать документы, но и создавать, редактировать их. Веб должен был стать местом совместного творчества и сотрудничества для всего человечества. Но что-то пошло не так.

Есть примеры удачной реализации совместного творчества, как Википедия, децентрализованный хостинг сайтов и пиринговые социальные сети. Это предвестники того, каким может стать веб на основе новой технологии Solid, которую разработал Тим Бернерс-Ли совместно с группой исследователей из Массачусетского технологического института. Это венец десятилетий концептуальной работы, которой занимался Бернерс-Ли.