1. Что это было?
2. Почему у них не получилось?
3. Что это значит для будущего блокчейна и криптовалют?

… или самые частые ошибки фаундеров.

Признаюсь: сам запускал стартапы. Какие-то более успешно, какие-то менее. Если вдруг деньги кончались, занимался консалтингом (как тот самый кот). В итоге, знакомился с разными хорошими людьми, что помогало и мне, и им двигаться дальше.

За это время мне удалось оценить сотни pitch decks. Удалось поработать со стартапами, чтобы улучшить идеи, реализовать и запустить их продукты.

Здесь собраны самые частые ошибки, которые я видел за последние 10 лет. Все они основаны либо на личном опыте, либо на опыте фаундеров, с кем я общался. Часть ошибок типична только для русскоговорящих фаундеров, но большинство из них — универсальны.

Итак, как же фаундеры стреляют себе в ногу?

Как я обучал агента собирать клетку 2048 в игре “2048”

Привет! Меня зовут Ринат Максутов, я работаю в подразделении Intelligent Engineering Services департамента Technology российского офиса компании Accenture, и веду проекты по заказной разработке. За свою многолетнюю карьеру в Аксенчере я попробовал много разных областей: мобильная разработка, фронт-энд, бэк-энд и даже дата саенс с машлерном. Однако мой рассказ будет не про работу, а про хобби. Мне очень нравится учиться и исследовать новые области на собственных pet-проектах. Сегодня я расскажу об одном из них - как я учил Reinforcement learning (RL) агента играть в известную головоломку “2048”. В статье намеренно не будет кода, математики, state-of-the-art подходов и новейших открытий в области, поэтому люди, хорошо знакомые с RL, ничего нового для себя не откроют. Эта статья - рассказ для широкой публики о том, как я поставил себе необычную цель и достиг ее. Приглашаю всех под кат!

s = a+b;
z = s-a;
t = b-z;

Программист ставит себе на тумбочку перед сном два стакана. Один с водой — на случай, если захочет ночью пить. А второй пустой — на случай, если не захочет.

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

А еще я хотел бы пригласить вас на Golang Conf 2019, которая пройдет 7 октября в Москве. Я член программного комитета конференции, и мы с коллегами выбрали много не менее хардкорных и очень, очень интересных докладов. То, что я люблю!

Под катом передаю слово автору.

Мою предыдущую статью «История IT. Когда компьютеры были большими…» мы завершили концом 80-х, когда произошло два знаменательных события. Во-первых, появился ООП и объектный язык C++. А во-вторых, появились персоналки, и это принципиально изменило задачи, стоящие перед IT-разработкой.

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

Главное изменение в том, что персоналки сделали компьютеры доступными небольшим компаниям. Потребовались системы автоматизации бизнес-процессов, которые сильно отличаются в разных компаниях. Типовую систему сделать сложно: сейчас такие системы уже есть, например, 1C, а в то время их не существовало. Как раз эту задачу помог решить ООП. Эту часть истории развития IT и концепций, которые тогда появились и до сих пор используются, я расскажу в этой статье.

Введение

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

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

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

Время жизни (lifetime)

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

Привет, я Дмитрий Логвиненко — Data Engineer отдела аналитики группы компаний «Везёт».

Я расскажу вам о замечательном инструменте для разработки ETL-процессов — Apache Airflow. Но Airflow настолько универсален и многогранен, что вам стоит присмотреться к нему даже если вы не занимаетесь потоками данных, а имеете потребность периодически запускать какие-либо процессы и следить за их выполнением.

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

Что обычно видишь, когда гуглишь слово Airflow / Wikimedia Commons

• Локальный девелопмент.
• Функции развертывания.
• Мультиконтейнерные приложения.
• Обнаружение служб service discovery.
• Масштабирование сервиса.
• Run-once задания.
• Интеграция с Maven.
• «Скользящее» обновление.
• Создание кластера БД Couchbase.

• Postgres: bloat, pg_repack и deferred constraints
  
• Ограничения (сonstraints) PostgreSQL: exclude, частичный unique, отложенные ограничения и др
  

Привет, меня зовут Иван, и я делаю Авито Доставку. Когда пользователь покупает товар с доставкой, мы показываем ему список отделений служб доставки с ценами. Цена доставки может меняться от отделения к отделению. Мы смотрим на область карты, где покупатель ищет товар и информацию по объявлению, например, координаты продавца, вес и размеры товара. И на выходе показываем человеку список отделений с адресами и ценой доставки в каждое из них.

В ходе разработки калькулятора цены доставки возникла такая задача: есть структура базы данных PostgreSQL и запрос к ней от сервиса на Go. Нужно заставить всё это работать достаточно быстро. В итоге нам удалось поднять пропускную способность сервиса с 50 до 5000 RPS и выявить пару нюансов при общении сервиса с базой. Об этом и пойдёт рассказ.