UPD. К сожалению, многие комментарии скатываются в политоту, но есть несколько интересных технических мыслей. Постепенно вынесу их в конец статьи.

---

Последнее время всё чаще пробегают новости про «суверенный интернет», «отключение интернета» и прочие ужасы. Однако, по состоянию на начало 2017 года, отключить российский сегмент от остальной сети и оставить его работоспособным представляется маловероятным.

Давайте попробуем рассмотреть детально.

Настоящие программисты — это облака, big data, high load… А у нас — практически DIY. 2 установки — уже тиражирование, 100 штук — производство… Но зато атомные ледоколы, маневровые локомотивы, трактора, шлюзы, мосты, опускающиеся вниз от лишнего асфальта, беспилотники размером в дом, 50 человек персонала на цех длиной больше двух километров… и надежность, надежность, надежность… И пяток гендиректоров в костюмах прямо на поле при демонстрации системы на тракторе…


Обычное окончание отладки — убираем антенны с путеправильной машины

Итак… пришла просьба от коллег — написать ТКП (технико-коммерческое предложение) на хитрый GPS-трекер. И комментарии, что большие и настоящие делать отказались.

Кратко суть проблемы: нужно было много админок, написал генератор админок.

Как работает: описали сущности в JSON; сгенерировали схему БД (PostgreSQL); сгенерировали процедуры для БД; сгенерировали сервер (NodeJS или PHP); сгенерировали админку (HTML файл); накатили, задеплоили, скопировали все это; можно приступать к работе;

Содержание: как дошёл до этого; почему не взял готовое решение; что получилось; что НЕ получилось; как оно работает; про UX;

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

Среди беспорядка найдите простоту; среди раздора найдите гармонию; в трудности найдите возможность...
(С) Альберт Эйнштейн

Статей о микросервисах, их достоинствах и недостатках в последнее время написано немало. Однако как-то редко кто пишет об имплементации микросервисной архитектуры, и прежде всего, именно об микросервисе, как о кирпичике, из которой и строится потом здание такого приложения. Я попытался восполнить этот пробел, и поделиться своим опытом в разработке http-микросервиса, вылившемся в конечном счёте в небольшую библиотеку под не оставляющим места для сомнений названием Microservice. Код написан на прекрасно подходящем для микросервисов, простом и удобном языке программирования Golang.

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

Тысяча диалектов

Знаете ли вы, что спецификация языка программирования С часто упоминает термин «объект»? Нет, это не объект в том понимании, как он описывается в ООП — объект в С определяется как «блок данных в среде выполнения, содержимое которого может представлять некоторое значение». В этом понимании объекта имеет смысл говорить о, например, «объекте типа char».

Термин «метод» достаточно распространён, но вы можете встретить программистов, которые будут говорить исключительно «функция-член класса». Язык программирования Java, поэтому, то ли имеет, то ли не имеет функций, в зависимости от того, кого вы об этом спросите. Термины «процедура» и «подпрограмма» иногда используются как аналог «функции», но в некоторых языках программирования (например, Pascal) процедура это совершенно не то же самое, что функция.

Даже в рамках одного языка программирования мы, бывает, путаемся.

Преамбула

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

Все паттерны разработки, как правило, имеют свои плюсы и минусы. Таким образом, преимущества зачастую носят субъективный характер и разработчику следует выбирать подходящие модели в зависимости от условий и контекста.

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

Реми Кулом (слева) с компьютерной программой Crazy Stone против гроссмейстера Норимото Ёды

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

У классической игры с 2500-летней историей очень простые правила, но компьютерные программы даже близко не могут подобраться к победе над лучшими гроссмейстерами, пишет Wired.

За свой относительно небольшой опыт работы (порядка 6 лет) я довольно часто слышал фразы опытных и начинающих программистов — «Я чувствую, что это должно работать», «У меня есть ощущение, что этот метод работать не будет», «Давайте сделаем интуитивно-понятный интерфейс» и так далее. Всё это — проявление интуиции в процессе разработки и программировании.
О ней и пойдёт дальше разговор.


Взято с сайта oprah.com

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

И, надеюсь, кому-нибудь это может оказаться полезно, ибо кто-нибудь может чего-нибудь не знать, или, наоборот, окажется полезно мне, если кто-нибудь покажет что-нибудь ещё/укажет на изъяны в моих знаниях.

• Параллелизм (часть 1, текущая)
  
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2)
  
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3)
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

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

Постановка задачи

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

К такому количеству записей опробованные SQL/NoSQL системы хранения оказались плохо приспособлены, поэтому клиент предложил с нуля разработать специализированное решение.

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

Введение

Не в коем случае не хочу утверждать, что это гайд по тому, как вводить Scrum, — это лишь опыт введения и адаптирования Scrum’а под нужды одной компании. Данный опыт может быть интересен/полезен, как новичкам: основные наводки, этапы, циклы и т.п., так и профессионалам: обсудить что пошло не так, чего делать не стоило и т.п. Подчеркну, то что у нас вышло — это лишь нечто напоминающее Scrum.

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

Привет! Я Катя, и я – трудоголик тестировщик самого популярного приложения для новых знакомств.

Итак, раннее утро, вы – мобильный QA. Вы приходите на работу, завариваете крепкий кофе и хотите взять пару мобильных устройств для тестирования новой фичи, осознавая, какие муки выбора вам предстоят. Что это будут за устройства?

Рано или поздно каждый мобильный тестировщик задаётся вопросом, на каком количестве устройств тестировать новый функционал, чтобы поймать максимальное количество девайсозависимых багов, потратив минимум времени. Автотесты ещё не написаны, перед вами абсолютно новые фичи. И если с iOS есть хоть какая-то ясность, и список устройств ограничен, то Android «расплодился» в полнейший ад. Вы удивитесь, но для счастья нужно всего три–четыре Android-устройства. Я хочу рассказать, как с точки зрения опытного тестировщика их выбрать.

Да, это пока не широко распространено. Обработка естественного языка еще недостаточно развита и не интегрирована с разработкой. Также, как нет и удобных способов интегрировать код с поиском или виртуальным помощником (таким как Siri). Голосовые команды имитируют GUI пути (щелчок-открыть-щелчок). Семантический Веб пытается познакомить приложения со смыслом, но все еще не может достигнуть широкой аудитории. Behavior-driven development (BDD) полагается на DSL (предметно-ориентированный язык), который близок к естественному, но этого все еще недостаточно, чтобы научить ваш код говорить.

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

• который будет адаптирован к естественному языку
• которому будет легко обучить широкий круг людей
• который может выступать связующим звеном между естественным языком и компьютерными сущностями
• который сможет создавать окружение в как можно большем количестве областей программной инженерии
  

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

А для тех, кто открыл ООО, мы подготовили: 10 вещей, которые обязательно нужно сделать после регистрации ООО

Если честно, то не совсем и сказка, а суровая жизнь. Но время ведь потеряно совершенно настоящее, хоть и с пользой. А началось всё совершенно случайно. На одном сайте один умный товарищ написал пост о гипотезе Эйлера. Суть достаточно проста. Гипотеза Эйлера утверждает, что для любого натурального числа n>2 никакую n-ю степень натурального числа нельзя представить в виде суммы (n-1) n-х степеней других натуральных чисел. То есть, уравнения:


не имеют решения в натуральных числах.

Ну собственно так оно и было до 1966 года…

Для одной из задач мне понадобился синтаксический анализатор русскоязычных текстов. Что это такое. Например, у нас есть предложение «Мама мыла раму». Нам нужно получить связи слов в этом предложении в виде дерева:


Из этого дерева понятно, что связаны слова «мама» и «мыла», а также «мыла» и «раму», а слова «мама» и «раму» напрямую не связаны.

Статья будет полезна тем, кому понадобился синтаксический анализатор, но не понятно, с чего начать.

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