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

Привет! Это Кирилл, куратор потока «Менеджмент». На Хабре публиковалась масса постов, в которых предприниматели делятся с читателями своим опытом, переводов текстов матёрых инвесторов и других текстов об управлении бизнесом. Чтобы в них было проще ориентироваться, мы сделали очередную подборку материалов — на этот раз о стартапах. Под катом — ссылки на тексты, которые точно стоит прочитать, если интересуетесь управлением, деньгами и историей отечественной IT-индустрии.

Любой разработчик может уйти в сторону оси "Технологии" и делать свой стек технологий сильнее - становиться ведущим или старшим разработчиком. Можно попробовать прокачать себя в оси "Продукт" - уйти в PM и потом пойти дальше по матрице компетенций и расти по вертикали. Но есть еще одна ось, о которой можно много говорить, о которой много пишут, писали, и будут писать - "Люди". Управление людьми, работа с командой напрямую, выстраивание своих локальных процессов разработки - участь TeamLead

А не пора ли нам шардить коллекции?
Не-е-е:

• у нас нет времени, мы пилим фичи!
• CPU занят всего на 80% на 64 ядерной виртуалке!
• данных всего 2Tb!
• наш ежедневный бекап идет как раз 24 часа!

В принципе, для большинства проектов вcё оправдано. Это может быть еще прототип или круг пользователей ограничен… Да и не факт, что проект вообще выстрелит.
Откладывать можно сколько угодно, но если проект не просто жив, а еще и растет, то до шардинга он доберется. Одна беда, обычно, бизнес логика не готова к таким "внезапным" вызовам.
А вы закладывали возможность шардинга при проектировании коллекций?

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

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

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

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

Замечания и предложения приветствуются.

В последнее время было достаточно много обсуждений производительности в PHP. И даже несмотря на то, что у нас есть PHP8, JIT и куча других улучшений, многие по-прежнему продолжают жаловаться на то, что PHP "недостаточно производительный". Что PHP - это язык, подходящий только для модели запрос-ответ. Что PHP слишком медленный и его не нужно использовать для высоконагруженных систем. С одной стороны от части всё это правда. Если мы строим какую-то систему, для которой вопрос производительности критичен, то использовать классический блокирующий PHP явно не стОит. Большая часть функций и библиотек PHP созданы для работы в традиционном блокирующем окружении, что уже подразумевает собой не самую высокую производительность. Однако PHP может работать быстро, более того, он может работать очень быстро. Как? Обычно у нас может быть две причины, из-за чего будет проседать производительность: мы либо совершаем какие-то сложные вычисления, либо у нас есть блокирующй ввод-вывод. Первое к сожалению (или к счастью) мы не можем решить в PHP. Но блокирующий ввод-вывод для PHP совсем не проблема. В PHP-сообществе есть люди, которые пишут асинхронный код уже на протяжении несколько лет. Конечно одновременно с этим бОльшая часть сообщества по-прежнему считает асинхронный PHP - дикостью. Я часто слышал: "Ты наверно совсем отчаянный, если собираешься писать что-то асинхронное на PHP". По правде говоря, у нас у всех есть это предубеждение, что PHP не подходит для подобного рода задач. И в большинстве случаев это предубеждение основано на неверных представлениях о самой "асинхронности". Неверные предубеждения в свою очередь ведут к неправильным ожиданиям, что в свою очередь приводит к разочарованию и обвинениям в том, что PHP "не по-настоящему асинхронный".

Недавно Y Combinator опубликовал свой топ-2021 компаний. В нём перечислены 137 лучших стартапов из портфеля YC (по оценке их рыночной стоимости). Статистика впечатляет: совокупная оценка более $300 млрд, 125+ компаний стоимостью более $150 млн, стартапами создано более 60 000 новых рабочих мест!

Основатель Rebel Fund и председатель CrowdMed (YC W13) Джаред Хейман проанализировал список и делится своими выводами для инвесторов. Поскольку задача его фонда — выбирать и вкладывать капитал в лучшие 3-4% стартапов из каждого набора YC, он тщательно изучает достижения стартапов в прошлом. И пытается установить закономерности, которые позволят выявить будущих «единорогов» — it-компании стоимостью более $1 млрд.

Изучив 137 success stories топовых стартапов YC, Джаред отметил общие тенденции. Конечно, анализ исторических данных не может полностью заменить оценку команды разработчиков, рынка, продукта и привлекательности отдельного стартапа. Но есть закономерности, о которых следует помнить тем, кто инвестирует на ранних этапах или собирается вывести в лидеры свой стартап.

Осторожно, впереди туча графиков! 

На волне последних обсуждений темы собеседований, хочу задать аудитории Хабра вопрос: вы помните, как писали в резюме: "коммуникабельный, инициативный, быстро обучаюсь"? 

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

Итак, меня зовут Алексей, я QA Lead одной из команд в Plesk. Хочу поговорить о том, как увеличить пользу от технического собеседования, или что означают софт скиллы, и как они проявляют себя в реальной жизни. 

Добро пожаловать под кат.

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

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

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

Как вы думаете, что делают рекрутеры, когда видят "Alexandr, NOT OPEN FOR WORK"? Правильно, пишут "Алексей, рассматриваете вариант работать в X?" Я обычно игнорирую это, но тут мне предложили попытать счастья с Яндекс.Лавкой, и я не смог пройти мимо - интересно было, смогу ли я устроиться куда-нибудь, когда введут великий российский файерволл. К тому же за последние 3 года я проходил только два интервью, и мне показалось, что я не в теме, что нынче требуется индустрии. Блин, я оказался и вправду не в теме. И вы, скорей всего, тоже - об этом и статья.

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

Git имеет репутацию запутывающего инструмента. Пользователи натыкаются на терминологию и формулировки, которые вводят в заблуждение. Это более всего проявляется в "перезаписывающих" историю командах, таких как git cherry-pick или git rebase. По моему опыту, первопричина путаницы — интерпретация коммитов как различий, которые можно перетасовать. Однако коммиты — это не различия, а снимки! Я считаю, что Git станет понятным, если поднять занавес и посмотреть, как он хранит данные репозитория. Изучив модель хранения данных мы посмотрим, как новый взгляд помогает понять команды, такие как git cherry-pick и git rebase.

Сейчас 3 часа ночи 10 августа 2013 года. Бесконечный приступ паники не дает мне сомкнуть глаз. Как сумасшедший, я раз за разом прокручиваю только что написанный код в голове. Внезапно я осознаю, что в архитектуре приложения есть серьезная проблема. Я вскрикиваю и скатываюсь с кровати, спотыкаясь о свою девушку, я бегу как сумасшедший к своему компьютеру, чтобы все исправить. 

Я знаю, что этот день будет прекрасной солнечной субботой. Я снова буду работать 12 часов подряд. А стресс и горящий дедлайн снова не дадут мне уснуть. Как я докатился до всего этого?

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

Снимок сделал «Максимус», ультрамощный рентгеновский микроскоп в Центре Гельмгольца в Берлине. Он дает нам представление о поведении новых кристаллов времени, которые впервые были экспериментально созданы в лаборатории в 2016 году. Открытие обещает «выдающиеся новые прорывы в фундаментальных исследованиях», — говорится в материале, опубликованном командой ученых в Physical Review Letters.

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

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

Осторожно, в статье очень много иллюстраций.