Как стать автором
Обновить
31
Карма
0
Рейтинг
Григорий Кошелев @gnkoshelev

Team Lead

  • Подписчики 22
  • Подписки

Эти токсичные, токсичные собеседования

«Не всё так однозначно». ©
Это в контексте «вайтбординга» и алгоритмов.

Из рассмотрения выпали самые массовые группы разработчиков:
  • Стажёры — нулевой опыт «промышленной» разработки; студенты технического вуза на профильном факультете.
  • Джуниоры — «боевой» опыт до года или полутора лет; возможно, ещё студенты.

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

Единственно, под «вайтбордингом» я больше понимаю псевдокод, схемы и рисунки, чем настоящий код.

Чуть не уволили по статье… на Хабре

Я вообще был бы осторожен в сравнении работы в большой и в маленькой компаниях — это как сравнивать болид Формулы 1 и раллийный джип внедорожник. К тому же всё очень субъективно и индивидуально. Например, кому-то нравится работать в огромном опенспейсе, кому-то — в маленьком кабинете, а кому-то больше подходит «хоум-офис».
Или, вот, ещё пример: маленькая компания — один продукт — одна команда — 20 человек в разработке, большая компания — 15 продуктов — 300 человек в разработке. Кажется, 15 продуктов и 300 человек в разработке — это уже большая компания, но при этом-то каждая из команд не превышает таковую из маленькой. Получается, что при таком устройстве большая компания сохранит свойства маленькой?

Меня больше цепляет тема, которую поднимает автор — многие компании закрываются сами и закрывают своих сотрудников, чтобы их не увели. Кажется, что это путь в никуда: так ни новых крутых спецов не найти (они даже и знать не будут про такую компанию), ни старых не замотивировать (другие компании рассказывают про свои разработки, интересные задачи да плюшками балуют, наконец). Если классный специалист захочет найти новую работу — он её найдёт.

Относительно моего последнего опыта написания на Хабре — две статьи (одна в корп. блоге, вторая — нет): в обоих случаях коллеги помогли и с редактурой, и с вычиткой, и с идеями — две ночи вместе редактировали.

Сказ о маленькой стажировке в маленькой компании [Часть II]

Имел ввиду не косяки «as is», а скорее результат рефлексии по ним.
А потом уже из «Если хочешь хорошо и правильно — делай так, иначе получишь это, потому что вот» можно оставить «Если хочешь хорошо и правильно — делай так».

Такая вот теория оптимального управления из жизни.

Сказ о маленькой стажировке в маленькой компании [Часть II]

Кажется, что это дело (выписывание косяков) невозможно закончить, его можно только прекратить. :)
Осталось только «границу значимости» провести в нужном месте.

Так что с одной стороны статью вы писали не зря (очень даже не зря), а с другой — косяки все равно вылезут.
А косяки, да, неизбежны. Не зря же Milfgard здесь (да много, где) пишет про франчбук, который уже несколько лет пилится. Поди уже толщиной в том «Войны и Мира».

Сказ о маленькой стажировке в маленькой компании [Часть II]

Мотивационный опрос же!
— Не против ли вы %something%?
— Да, не против.
— Нет, не против.

Если серьёзно, то для таких случаев предусмотрен вариант «воздержаться».

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

Кажется, основная моя мотивация в написании этой статьи в том, чтобы продемонстрировать на живом примере возможность организовать содержательную и полезную стажировку, не имея огромных ресурсов. В компании и программистов-то на тот момент было 5-8 человек. А, значит, если мы смогли, то смогут очень многие.
Постарался вспомнить и привести все основные косяки процесса, чтобы можно было их учесть у себя и сделать лучше — тогда и не зря всё это писал!

Сказ о стажировке в маленькой компании или как мы с Контуром конкурировали [Часть I]

Вчерашние стажеры учат стажеров?

Вчерашний стажёр учится делать code review, выстраивать горизонтальные связи в команде. Писать код — это далеко не единственное, что должен уметь разработчик. Таким образом, с наставника можно снять часть ежедневной работы со стажёром и делегировать её менее опытному коллеге, прокачивая, тем самым, и его навыки командной работы. При этом весь процесс по-прежнему контролируется наставником.

Спасибо за статью, хороший разбор.

Спасибо за такую оценку.

Сказ о стажировке в маленькой компании или как мы с Контуром конкурировали [Часть I]

По тексту может сложиться ложное впечатление, что маленькая компания == гибкая компания, но это далеко не всегда так. Нам в этом плане повезло, что смогли за ориентировочно 2 недели развернуть процесс со стажировкой.

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

Как я создал SaaS-сервис, который приносит мне 1000 долларов в месяц

Выводы не совсем верные.

На сайте nalog.ru можно глянуть отчётность по регистрации ЮЛ и ИП. Ниже статистика по ИП.
За 2016 год в РФ зарегистрировано: 705 175
Всего действующих на начало 2016 года: 3 640 230
Всего действующих на начало 2017 года: 3 732 657

Попробуем прикинуть тренд. Соотношение «новых» к «общему количеству» ~ 1 к 5. Если за год (в действительности — намного дольше) выбрать рынок полностью, то в последующие годы (при сохранении темпов регистрации ИП) мы получим рынок в 5 раз меньший, а не нулевой.

Так что причина всё же в
а во-вторых появились конкуренты, которые делают парсеры раза в два дешевле.


И, возможно, в поиске целевой аудитории (узким был именно поиск, а не рынок).

Как я создал SaaS-сервис, который приносит мне 1000 долларов в месяц

Боюсь, что вопрос не по адресу, т.к. перевод.

Со своей стороны могу рассказать про «коридорный тест»:
  1. Выходим в коридор
  2. Ловим случайного человека
  3. Вводим в контекст за одну-две минуты
  4. Показываем ему продукт/веб-страницу/макет/whatever
  5. Задаём один вопрос: что ещё нужно?
  6. Аккуратно фиксируем все идеи

На повторяющиеся идеи как раз и стоит обращать внимание. «Коридорный тест» имеет продолжение и в работе с гипотезами (те идеи, полученные на предыдущем этапе): всё тоже самое, но проверяем гипотезы на состоятельность.

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

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

Ещё один тип XSS-атаки на сайт

Что интересно, вредоносный URL в .htaccess тот же самый (is.gd/J87Pzs), а гугл по такой строке выдаёт информацию по около двум десяткам сайтов, заражённых путём внедрения скрипта на страницу.

При этом остаётся загадкой, по каким правилам с конечного URL (home-income-business.com/sfi/i/qwe) отдаётся вредоносный скрипт. Вероятно, что он завязан на IP-адреса операторов сотовой связи (= пользователей мобильного интернета), это косвенно подтверждается приведённым вами примером (мобильные устройства).

Передача GPS-трека по SMS

В моём случае для кодирования 10 точек (без учёта меток времени и флагов) потребуется 443 бита против 360 бит (на 18.7% эффективнее); с другой стороны, если считать, что все точки в пределах одной улицы (как в вашем примере), то можно добиться и лучшего результата. В любом случае, стоит ознакомиться с алгоритмом, спасибо!

Для нас важным результатом было:
1. В трети случаев точки помещались в одну маленькую СМСку.
2. В подавляющем большинстве весь трек укладывался бы в одну жирную СМС (за редким исключением, когда трек мог состоять из ~ 100-200 точек).
3. Заголовок, тело и каждая точка трека занимали целое число байт.
4. Кодирование (не сжатие) давало предсказуемый результат по длине (цель не столько в упаковке как можно большего числа точек, сколько в упаковке заранее известного достаточного количества точек).

Передача GPS-трека по SMS

Если перефразировать 1 и 3 — можно попробовать заморочиться за собственное кодирование на основе 7-битных символов. Полезная нагрузка для текущего решения — 120 байт, а максимально возможная — 140 байт, то есть возможен прирост до 16.5%. Оптимизация же самих данных давала от 30% на каждом шаге (переход от наивной реализации вообще в разы увеличил объём переданных полезных данных). Так что такое решение бы стало следующим шагом.

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

Одини из поинтов статьи заключался в том, что в 2014 году (да и уже завтра — в 2017 году) в эпоху 4G, без пяти минут 5G, домашнего интернета до 300 МБит могут возникать ситуации, когда нельзя бездумно разбрасываться данными. Если бы я не вмешался в разработку алгоритма (Base64 был зафиксирован), то на полном серьёзе собирались использовать формат, который позволял бы передать только четыре точки в одинарной СМСке, когда весь трек состоит из десятков (в некоторых случаях — из сотен) точек. К сожалению, мы пережили то время, когда программирование было искусством.

Передача GPS-трека по SMS

Почитал про контекстно-адаптивное сжатие — а не слишком ли малый объём данных для применения таких методов?

Передача GPS-трека по SMS

Примеры декодирования данных:
    public static final DateTime ERA_DATE = DateTime.parse("2014-01-01T00:00:000Z");
    public static final int SEC_SCALE = 4;
    public static final int SEC_TO_MILLIS = 1000;

    public DateTime decodeDateTime(byte first, byte second, byte third, byte fouth) {
        long time = (first & 0x1FL)<<24 | (second & 0xFFL)<<16 | (third & 0xFFL)<<8 | (fouth & 0xFFL);
        return ERA_DATE.plus(time * SEC_SCALE * SEC_TO_MILLIS);
    }

    public DateTime decodeOffset(DateTime date, byte first, byte second) {
        long offset = (first & 0xFFL)<<8 | (second & 0xFFL);
        offset *= SEC_SCALE;//в секундах
        offset *= SEC_TO_MILLIS;//в миллисекундах
        return date.plus(offset);
    }


Тут можно отметить две вещи:
1. Нужно не забывать правильно очищать входные байты, которые «шарятся» между полями сообщения (пример с первым байтом при декодировании поля dateTime).
2. Используется Big Endian порядок байтов (замечание актуально только для платформ/языков, где используется другой порядок), так как от «расшаренных» байтов под флаги откусываются старшие биты старших байтов.

Передача GPS-трека по SMS

Добавил сводную информацию по бинарному формату + пример сообщения.

Передача GPS-трека по SMS

А это, между прочим, идея! Для всяких квестов и трофи-рейдов, например.

В предыдущем комментарии конечно же имелся ввиду «скриншот».

Передача GPS-трека по SMS

Как в один байт сохранить сдвиг на 1 час для указанной точности? С координатами сложно, т.к. за те же 2 часа можно долететь из Екатеринбурга в Санкт-Петербург, поэтому нужно понимать область применимости.

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

Передача GPS-трека по SMS

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

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

Передача GPS-трека по SMS

Даже в отсутствии загружаемых карт можно писать трек. Ведь карты нужны только для показа пользователю на экране телефона.
В простом варианте можно использовать оффлайновый «сриншот» кусочка карты, где мы знаем, например, координаты левой верхней и правой нижней точки прямоугольника. Если, конечно, речь не про северный полюс.

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Работает в
Зарегистрирован
Активность