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

Такая ситуация может происходить по разным причинам. Однако, чаще всего на старте разработки, бэкэнд просто не написан и клиент начинает без него. В таком случае начало разработки затягивается на 2-4 месяца.

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

Всем привет. Меня зовут Дмитрий Андриянов. Два года я писал на React Native, сейчас работаю в Surf во Flutter отделе и уже более полутора лет пишу на Flutter.

В первой части статьи я рассказал про основные различия между React Native и Flutter.
В этой части расскажу про различия между React Native и Flutter при создании UI для Android и iOS.

Школа 42 славится своей революционной системой обучения: там нет учителей, студенты сами проверяют друг у друга работы, платить за учебу не нужно. При этом школе удается готовить крутейших программистов, которых с руками отрывают ведущие компании мира. Мне было страшно любопытно взглянуть на эти чудеса собственными глазами, и как сотруднику GeekBrains (ведь наша главная задача — учить IT-специалистов), и как разработчику. Во время путешествия по США мне представился такой шанс, и я его не упустил.

Предприятие «Воронежстальмост» (бывший Воронежский мостовой завод) основано в 1948 году и является ведущей российской компанией по производству металлических пролетных конструкций мостов любых типов, размеров и сложности. Производственные площади завода и имеющееся оборудование позволяют изготавливать до 55 тысяч тонн металлоконструкций в год, на предприятии трудятся более 1800 рабочих и инженеров. Компания широко использует в работе компьютерные технологии, система менеджмента качества и сварочное производство сертифицированы в соответствии с международными стандартами.

Мы уже давно привыкли, что крупные IT-компании занимаются не только выпуском продуктов и оказанием услуг, но и активно участвуют в развитии интернет-инфраструктуры. DNS от Google, облачные хранилища и хостинг Amazon, дата-центры Facebook по всему миру — пятнадцать лет назад это казалось слишком амбициозным, а сейчас является нормой, к которой все привыкли.

И вот, четверка крупнейших IT-компаний в лице Amazon, Google, Microsoft и Facebook дошли до того, что начали вкладываться не только в непосредственно дата-центры и серверы, но и в сами магистральные кабели — то есть зашли на территорию, которая традиционно являлась зоной ответственности совершенно иных структур. Причем, судя по выводам в блоге APNIC, упомянутый квартет технологических гигантов замахнулся не просто на наземные сети, а на магистральные трансконтинентальные линии связи, т.е. на всем нам знакомые подводные кабели.



Самое удивительное, что острой необходимости в новых сетях сейчас нет, но компании активно наращивают пропускную способность «про запас». К сожалению, найти внятную статистику о мировой генерации трафика почти невозможно благодаря многочисленным маркетологам, которые оперируют размерностями вида «65 миллионов постов в инстаграме ежедневно» или «N поисковых запросов в Google» вместо прозрачных и понятных техническим специалистам петабайт. Можно осторожно предположить, что ежедневный трафик составляет ≈2,5*10^18 байт или около 2500 петабайт данных.

Привет, Хабр! Представляю вашему вниманию перевод статьи «PoW is Efficient» автора Dan Held.

Вступление

Большинство людей думает, что энергия, потраченная на Proof-Of-Work (далее PoW), тратится впустую. В этой статье я расскажу, почему все основано на энергии, включая деньги. А также почему оценка потребления энергии субъективна, и как стоимость потраченной на PoW энергии сравнить с другими системами. Эта статья содержит мысли многих людей из области криптовалют, я лишь собрал всё вместе.

Замена Disqus на Commento снизила размер страниц в 10 раз

Когда я завёл блог, то установил Disqus для комментариев. Это был естественный выбор: сайты по всему интернету ставили Disqus, его легко настроить, и есть бесплатный вариант использования. Я спокойно интегрировал движок комментариев и двинулся дальше.

Но вот в чём дело: я всегда знал, что Disqus немного раздувает страницы. Я ведь писал о веб-производительности и обычно старался оптимизировать страницы. Но я просто предположил, что Disqus прибавляет немного лишних килобайт. Логика: если он сильно раздувает страницы, все бы уже давно отказались от него. Очевидно, Disqus старается не увеличивать трафик, верно?

Я ошибался.

В начале 2019 года мы (совместно с порталами Software-testing.ru и Dou.ua) провели исследование уровня оплаты труда QA-специалистов. Теперь мы знаем сколько стоят услуги тестировщиков в разных уголках планеты. А ещё мы знаем какими знаниями и опытом должен владеть QA-специалист, чтобы сменить душный кабинет и скромный оклад, на пляжный шезлонг и толстую пачку валюты. Хотите узнать обо всём подробнее? Читайте нашу статью.

Портативная пишущая машинка Unis tbm de Luxe, произведена в Югославии, г. Сараево. Самый распространенный экземпляр на постсоветском пространстве, клавиши на кириллице.

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

От переводчика: перевели для вас статью Илада Леева о переходе с Python на Go. Статья будет полезна не только начинающим программистам, но и всем, кто так либо иначе интересуется Go.

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

Постепенное «созревание» Go, обширное комьюнити и тот факт, что все больше компаний принимают этот язык на вооружение после успешных тестов, заставили меня обратить на него внимание и углубиться в литературу. Но этот пост не о том, что лучше — Python или Go: сравнений в сети огромное количество. По моему мнению, все зависит от области применения. Я собираюсь рассказать о том, почему выбрал Go, дав несколько советов и ссылок на полезные ресурсы для всех интересующихся темой.

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

“Кто виноват?”

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

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

На днях признал свою вину в суде мошенник из США (Северная Каролина), который смог заработать обманным путем более $3 млн за четыре года. Он получал деньги от владельцев ПК и ноутбуков, которым мошенник представлялся сотрудником техподдержки Microsoft. Зовут скамера Бишап Миттал (Bishap Mittal), сейчас ему 24 года.

Арестовали его 12 марта, через несколько дней Миттал признал свою вину. Работал он не сам, а на пару с сообщником (имя сообщника пока что остается неизвестным). Злоумышленники создавали сайты, которые принадлежали реальной компании Capstone Technologies LLC.

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

Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.

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

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

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

Все это мы на своих проектах делаем.

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

Полбеды, если он просто шутит, вроде, «разработка приносит мне столько бабок, что поработаю два часа и найму трех нищих врачей стричь мне лужайку». Хуже, когда говорит серьезно: «Ты зря стал писать код. Вся ирония этой индустрии в том, что став хорошим разработчиком, ты обретаешь навыки, которые приводят тебя к выводу, что разработчиком быть плохо».

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

Компании по всей планете переходят в облака — настоящий «техтонический» сдвиг. Изменения происходят не только из потребности использовать в облаках софт, но и благодаря тому, что компании переосмысливают свои корпоративные стратегии, размещение своих внутренних данных и контента, политику конфиденциальности, системы, безопасность и даже культуру. Исследовательская компания Gartner, основываясь на данных рынка, оценивает затраты на переход в облака в IT сфере в 1,3 трлн. долларов к 2020-му году. Большая часть этих расходов ведёт к достижению целей компаний по улучшению эффективности, увеличению денежного потока и общей экономии.

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

От переводчика: этот текст — перевод записи в личном блоге Михаэля Штапельберга (Michael Stapelberg) видного open source-разработчика (профиль GitHub), который внес значительный вклад в развитие Debian.

---

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

Debian был частью моей жизни на протяжении 10 лет.

Несколько недель назад, на посвященной Debian встрече, проходившей в Цюрихе, я встретился со своими старыми друзьями, которых не видел много лет. Когда я уже ехал домой на велосипеде, меня осенило, что все обсуждаемые нами темы так или иначе сводились к тому, что мы обсуждали с ними в прошлый раз. Мы дискутировали о достоинствах systemd, который вновь привлек внимание участников open source сообщества, затронули тему процессов в Debian. Кульминацией стало обсуждение демократии как таковой и соответствующие теоретические и практические ошибки. Но, на самом деле, это уже чисто швейцарская тема.

Это не обзор прошедшего митапа, я просто хочу объяснить, что побудило меня задуматься о своем текущем отношении к Debian и подходит ли он мне.

Итак, я принял решение, которое должен был принять давно: я сворачиваю свое участие в развитии Debian.

Несколько месяцев назад мы вышли на AppSumo с 93% скидкой на свой продукт. Подготовка заняла у нас полтора месяца, и в процессе мы не нашли подробного гайда или описания, что от нас требуется, как все будет происходить и как мы могли бы улучшить результат. Мы общались с несколькими компаниями, которые прошли этот путь до нас, но и этой информации казалось нам недостаточно. Пройдя этот путь от и до, Мария Бочева, Business Development Manager в OWOX BI, составила пошаговое руководство, которое поможет вам подготовиться к запуску и сэкономить время.

Прим. перев.: Оригинальная статья была написана инженером из Швеции — Christian Abdelmassih, — который увлекается архитектурой уровня enterprise, ИТ-безопасностью и облачными вычислениями. Недавно он получил степень магистра в области Computer Science и спешит поделиться своим трудом — магистерской диссертацией, а точнее — её частью, посвящённой проблемам изоляции контейнеризированного [и запущенного в Kubernetes] приложения. В качестве «клиента», для которого была подготовлена эта исследовательская работа, выступает ни много ни мало полиция его родины.



Оркестровка контейнеров и облачные (cloud-native) вычисления стали очень популярными в последние годы. Их адаптация дошла до такого уровня, что интерес к ним проявляют даже финансовые предприятия, банки, госсектор. На фоне других компаний их выделяют обширные требования в области безопасности информации и ИТ.

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

Продолжая серию наших публикаций, мы решили, что для понимания азов «цифровой химии» нужно немного рассказать про суть бизнеса компании. Понятно, по пути будем упрощать, чтобы не превращать рассказ в занудную лекцию с перечислением всей таблицы Менделеева (кстати, 2019 год – официально год периодического закона, в честь 150-летия его открытия).

Многие люди при ответе на вопрос «Что такое нефтехимия и какие продукты она создает?» уверенно отвечают — топливо, бензин и прочее жидкое-горючее. На самом деле, мягко говоря, это не совсем так. Как нефтехимическая компания мы занимаемся в основном переработкой побочных продуктов добычи нефти и газа и производством синтетических материалов, которые составляют значительную часть окружения каждого из нас. Есть мнение, что из 5 любых предметов, которые нас окружают в любой момент времени, 4 созданы благодаря нефтехимии. Это корпуса ноутбуков, ручки, бутылки, ткани, бамперы и шины для автомобилей, пластиковые окна, упаковка любимых чипсов, водопроводные трубы, контейнеры для еды, медицинское оборудование и расходники… В общем, вот:



Меня зовут Алексей Винниченко, я отвечаю в СИБУРе за направление «Продвинутая аналитика». С помощью аналитических моделей мы настраиваем оптимальные режимы технологических процессов, минимизируем риски поломок оборудования, предсказываем рыночные цены на сырье и продукты, а также многое другое.

Сегодня расскажу, что это за продукты и как мы производим их из преимущественно попутного нефтяного газа.