Да, мы можем заменить x на n и получить некоторую оценку, но мы не можем тривиальным образом утверждать из-за огрубления, что она будет точнее прочих предложенных:
Наиболее точный ответ на последний вопрос предлагалось выбрать из внушительного списка вариантов.
Справедливости ради, остаётся недоказанной равносильность перехода от сложности алгоритма for-for-toBinaryString к произведению сложности вложенных циклов for-for и сложности метода toBinaryString, поскольку x в оценке O(log²(x)) метода зависит от состояния цикла.
Выше предлагается эмпирически способ подсчёта вычислительной сложности с засеканием времени. Ещё один альтернативный способ (без необходимости засекать время):
Заменяем все операции на увеличение счётчика.
Если количество операций может быть посчитано явно (без необходимости крутить цикл или рекурсию, то прибавляем сразу необходимое количество.
Делаем для n разного порядка и подбираем подходящую асимптотику.
Из рассмотрения выпали самые массовые группы разработчиков:
Стажёры — нулевой опыт «промышленной» разработки; студенты технического вуза на профильном факультете.
Джуниоры — «боевой» опыт до года или полутора лет; возможно, ещё студенты.
По опыту проведения собеседований, как раз на интервью с кандидатами из указанных групп на ура заходят задачи на алгоритмы и «вайтбординг». И польза от этого определённая есть, поскольку по ним можно оценить обучаемость и умение формулировать свои мысли.
Единственно, под «вайтбордингом» я больше понимаю псевдокод, схемы и рисунки, чем настоящий код.
Я вообще был бы осторожен в сравнении работы в большой и в маленькой компаниях — это как сравнивать болид Формулы 1 и раллийный джип внедорожник. К тому же всё очень субъективно и индивидуально. Например, кому-то нравится работать в огромном опенспейсе, кому-то — в маленьком кабинете, а кому-то больше подходит «хоум-офис».
Или, вот, ещё пример: маленькая компания — один продукт — одна команда — 20 человек в разработке, большая компания — 15 продуктов — 300 человек в разработке. Кажется, 15 продуктов и 300 человек в разработке — это уже большая компания, но при этом-то каждая из команд не превышает таковую из маленькой. Получается, что при таком устройстве большая компания сохранит свойства маленькой?
Меня больше цепляет тема, которую поднимает автор — многие компании закрываются сами и закрывают своих сотрудников, чтобы их не увели. Кажется, что это путь в никуда: так ни новых крутых спецов не найти (они даже и знать не будут про такую компанию), ни старых не замотивировать (другие компании рассказывают про свои разработки, интересные задачи да плюшками балуют, наконец). Если классный специалист захочет найти новую работу — он её найдёт.
Относительно моего последнего опыта написания на Хабре — две статьи (одна в корп. блоге, вторая — нет): в обоих случаях коллеги помогли и с редактурой, и с вычиткой, и с идеями — две ночи вместе редактировали.
Имел ввиду не косяки «as is», а скорее результат рефлексии по ним.
А потом уже из «Если хочешь хорошо и правильно — делай так, иначе получишь это, потому что вот» можно оставить «Если хочешь хорошо и правильно — делай так».
Такая вот теория оптимального управления из жизни.
Кажется, что это дело (выписывание косяков) невозможно закончить, его можно только прекратить. :)
Осталось только «границу значимости» провести в нужном месте.
Так что с одной стороны статью вы писали не зря (очень даже не зря), а с другой — косяки все равно вылезут.
А косяки, да, неизбежны. Не зря же Milfgardздесь (да много, где) пишет про франчбук, который уже несколько лет пилится. Поди уже толщиной в том «Войны и Мира».
— Не против ли вы %something%?
— Да, не против.
— Нет, не против.
Если серьёзно, то для таких случаев предусмотрен вариант «воздержаться».
А по теме, очень познавательная статья, но я думаю что очень редко можно встретить подобные стажировки в нашей стране. Обычно тебя нагружают кучей мануалов и если через неделю или две не разберешься, отправляют домой…
Кажется, основная моя мотивация в написании этой статьи в том, чтобы продемонстрировать на живом примере возможность организовать содержательную и полезную стажировку, не имея огромных ресурсов. В компании и программистов-то на тот момент было 5-8 человек. А, значит, если мы смогли, то смогут очень многие.
Постарался вспомнить и привести все основные косяки процесса, чтобы можно было их учесть у себя и сделать лучше — тогда и не зря всё это писал!
Вчерашний стажёр учится делать code review, выстраивать горизонтальные связи в команде. Писать код — это далеко не единственное, что должен уметь разработчик. Таким образом, с наставника можно снять часть ежедневной работы со стажёром и делегировать её менее опытному коллеге, прокачивая, тем самым, и его навыки командной работы. При этом весь процесс по-прежнему контролируется наставником.
По тексту может сложиться ложное впечатление, что маленькая компания == гибкая компания, но это далеко не всегда так. Нам в этом плане повезло, что смогли за ориентировочно 2 недели развернуть процесс со стажировкой.
Во второй части приведу примеры, когда гибкость компании (в части скорости принятия решений) здорово нам помогла.
На сайте nalog.ru можно глянуть отчётность по регистрации ЮЛ и ИП. Ниже статистика по ИП.
За 2016 год в РФ зарегистрировано: 705 175
Всего действующих на начало 2016 года: 3 640 230
Всего действующих на начало 2017 года: 3 732 657
Попробуем прикинуть тренд. Соотношение «новых» к «общему количеству» ~ 1 к 5. Если за год (в действительности — намного дольше) выбрать рынок полностью, то в последующие годы (при сохранении темпов регистрации ИП) мы получим рынок в 5 раз меньший, а не нулевой.
Так что причина всё же в
а во-вторых появились конкуренты, которые делают парсеры раза в два дешевле.
И, возможно, в поиске целевой аудитории (узким был именно поиск, а не рынок).
Со своей стороны могу рассказать про «коридорный тест»:
Выходим в коридор
Ловим случайного человека
Вводим в контекст за одну-две минуты
Показываем ему продукт/веб-страницу/макет/whatever
Задаём один вопрос: что ещё нужно?
Аккуратно фиксируем все идеи
На повторяющиеся идеи как раз и стоит обращать внимание. «Коридорный тест» имеет продолжение и в работе с гипотезами (те идеи, полученные на предыдущем этапе): всё тоже самое, но проверяем гипотезы на состоятельность.
Из плюсов: быстрый фидбэк; как правило не требуется готового решения; новые идеи, которые не всегда можно увидеть замыленным взглядом.
Из минусов: выборка может быть не релевантна целевой аудитории; не в любой предметной области можно дать контекст за столь ограниченное время.
Что интересно, вредоносный URL в .htaccess тот же самый (is.gd/J87Pzs), а гугл по такой строке выдаёт информацию по около двум десяткам сайтов, заражённых путём внедрения скрипта на страницу.
При этом остаётся загадкой, по каким правилам с конечного URL (home-income-business.com/sfi/i/qwe) отдаётся вредоносный скрипт. Вероятно, что он завязан на IP-адреса операторов сотовой связи (= пользователей мобильного интернета), это косвенно подтверждается приведённым вами примером (мобильные устройства).
В моём случае для кодирования 10 точек (без учёта меток времени и флагов) потребуется 443 бита против 360 бит (на 18.7% эффективнее); с другой стороны, если считать, что все точки в пределах одной улицы (как в вашем примере), то можно добиться и лучшего результата. В любом случае, стоит ознакомиться с алгоритмом, спасибо!
Для нас важным результатом было:
1. В трети случаев точки помещались в одну маленькую СМСку.
2. В подавляющем большинстве весь трек укладывался бы в одну жирную СМС (за редким исключением, когда трек мог состоять из ~ 100-200 точек).
3. Заголовок, тело и каждая точка трека занимали целое число байт.
4. Кодирование (не сжатие) давало предсказуемый результат по длине (цель не столько в упаковке как можно большего числа точек, сколько в упаковке заранее известного достаточного количества точек).
Если перефразировать 1 и 3 — можно попробовать заморочиться за собственное кодирование на основе 7-битных символов. Полезная нагрузка для текущего решения — 120 байт, а максимально возможная — 140 байт, то есть возможен прирост до 16.5%. Оптимизация же самих данных давала от 30% на каждом шаге (переход от наивной реализации вообще в разы увеличил объём переданных полезных данных). Так что такое решение бы стало следующим шагом.
Закладываться на время получения сообщения нельзя, так как имеют место действия, временные интервалы между которыми могут быть неопределённой длины: момент формирования трека, момент упаковки в бинарный формат, момент создания сообщения, момент отправки с телефона, момент получения сообщения оператором и так далее.
Одини из поинтов статьи заключался в том, что в 2014 году (да и уже завтра — в 2017 году) в эпоху 4G, без пяти минут 5G, домашнего интернета до 300 МБит могут возникать ситуации, когда нельзя бездумно разбрасываться данными. Если бы я не вмешался в разработку алгоритма (Base64 был зафиксирован), то на полном серьёзе собирались использовать формат, который позволял бы передать только четыре точки в одинарной СМСке, когда весь трек состоит из десятков (в некоторых случаях — из сотен) точек. К сожалению, мы пережили то время, когда программирование было искусством.
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 порядок байтов (замечание актуально только для платформ/языков, где используется другой порядок), так как от «расшаренных» байтов под флаги откусываются старшие биты старших байтов.
Как в один байт сохранить сдвиг на 1 час для указанной точности? С координатами сложно, т.к. за те же 2 часа можно долететь из Екатеринбурга в Санкт-Петербург, поэтому нужно понимать область применимости.
Впрочем, пока писал статью — увидел ещё несколько возможных вариантов допущений и оптимизаций, но уж как было — так и рассказал.
Выше предлагается эмпирически способ подсчёта вычислительной сложности с засеканием времени. Ещё один альтернативный способ (без необходимости засекать время):
Это в контексте «вайтбординга» и алгоритмов.
Из рассмотрения выпали самые массовые группы разработчиков:
По опыту проведения собеседований, как раз на интервью с кандидатами из указанных групп на ура заходят задачи на алгоритмы и «вайтбординг». И польза от этого определённая есть, поскольку по ним можно оценить обучаемость и умение формулировать свои мысли.
Единственно, под «вайтбордингом» я больше понимаю псевдокод, схемы и рисунки, чем настоящий код.
джипвнедорожник. К тому же всё очень субъективно и индивидуально. Например, кому-то нравится работать в огромном опенспейсе, кому-то — в маленьком кабинете, а кому-то больше подходит «хоум-офис».Или, вот, ещё пример: маленькая компания — один продукт — одна команда — 20 человек в разработке, большая компания — 15 продуктов — 300 человек в разработке. Кажется, 15 продуктов и 300 человек в разработке — это уже большая компания, но при этом-то каждая из команд не превышает таковую из маленькой. Получается, что при таком устройстве большая компания сохранит свойства маленькой?
Меня больше цепляет тема, которую поднимает автор — многие компании закрываются сами и закрывают своих сотрудников, чтобы их не увели. Кажется, что это путь в никуда: так ни новых крутых спецов не найти (они даже и знать не будут про такую компанию), ни старых не замотивировать (другие компании рассказывают про свои разработки, интересные задачи да плюшками балуют, наконец). Если классный специалист захочет найти новую работу — он её найдёт.
Относительно моего последнего опыта написания на Хабре — две статьи (одна в корп. блоге, вторая — нет): в обоих случаях коллеги помогли и с редактурой, и с вычиткой, и с идеями — две ночи вместе редактировали.
А потом уже из «Если хочешь хорошо и правильно — делай так, иначе получишь это, потому что вот» можно оставить «Если хочешь хорошо и правильно — делай так».
Такая вот теория оптимального управления из жизни.
Осталось только «границу значимости» провести в нужном месте.
А косяки, да, неизбежны. Не зря же Milfgard здесь (да много, где) пишет про франчбук, который уже несколько лет пилится. Поди уже толщиной в том «Войны и Мира».
Если серьёзно, то для таких случаев предусмотрен вариант «воздержаться».
Кажется, основная моя мотивация в написании этой статьи в том, чтобы продемонстрировать на живом примере возможность организовать содержательную и полезную стажировку, не имея огромных ресурсов. В компании и программистов-то на тот момент было 5-8 человек. А, значит, если мы смогли, то смогут очень многие.
Постарался вспомнить и привести все основные косяки процесса, чтобы можно было их учесть у себя и сделать лучше — тогда и не зря всё это писал!
Вчерашний стажёр учится делать code review, выстраивать горизонтальные связи в команде. Писать код — это далеко не единственное, что должен уметь разработчик. Таким образом, с наставника можно снять часть ежедневной работы со стажёром и делегировать её менее опытному коллеге, прокачивая, тем самым, и его навыки командной работы. При этом весь процесс по-прежнему контролируется наставником.
Спасибо за такую оценку.
Во второй части приведу примеры, когда гибкость компании (в части скорости принятия решений) здорово нам помогла.
На сайте nalog.ru можно глянуть отчётность по регистрации ЮЛ и ИП. Ниже статистика по ИП.
За 2016 год в РФ зарегистрировано: 705 175
Всего действующих на начало 2016 года: 3 640 230
Всего действующих на начало 2017 года: 3 732 657
Попробуем прикинуть тренд. Соотношение «новых» к «общему количеству» ~ 1 к 5. Если за год (в действительности — намного дольше) выбрать рынок полностью, то в последующие годы (при сохранении темпов регистрации ИП) мы получим рынок в 5 раз меньший, а не нулевой.
Так что причина всё же в
И, возможно, в поиске целевой аудитории (узким был именно поиск, а не рынок).
Со своей стороны могу рассказать про «коридорный тест»:
На повторяющиеся идеи как раз и стоит обращать внимание. «Коридорный тест» имеет продолжение и в работе с гипотезами (те идеи, полученные на предыдущем этапе): всё тоже самое, но проверяем гипотезы на состоятельность.
Из плюсов: быстрый фидбэк; как правило не требуется готового решения; новые идеи, которые не всегда можно увидеть замыленным взглядом.
Из минусов: выборка может быть не релевантна целевой аудитории; не в любой предметной области можно дать контекст за столь ограниченное время.
При этом остаётся загадкой, по каким правилам с конечного URL (home-income-business.com/sfi/i/qwe) отдаётся вредоносный скрипт. Вероятно, что он завязан на IP-адреса операторов сотовой связи (= пользователей мобильного интернета), это косвенно подтверждается приведённым вами примером (мобильные устройства).
Для нас важным результатом было:
1. В трети случаев точки помещались в одну маленькую СМСку.
2. В подавляющем большинстве весь трек укладывался бы в одну жирную СМС (за редким исключением, когда трек мог состоять из ~ 100-200 точек).
3. Заголовок, тело и каждая точка трека занимали целое число байт.
4. Кодирование (не сжатие) давало предсказуемый результат по длине (цель не столько в упаковке как можно большего числа точек, сколько в упаковке заранее известного достаточного количества точек).
Закладываться на время получения сообщения нельзя, так как имеют место действия, временные интервалы между которыми могут быть неопределённой длины: момент формирования трека, момент упаковки в бинарный формат, момент создания сообщения, момент отправки с телефона, момент получения сообщения оператором и так далее.
Одини из поинтов статьи заключался в том, что в 2014 году (да и уже завтра — в 2017 году) в эпоху 4G, без пяти минут 5G, домашнего интернета до 300 МБит могут возникать ситуации, когда нельзя бездумно разбрасываться данными. Если бы я не вмешался в разработку алгоритма (Base64 был зафиксирован), то на полном серьёзе собирались использовать формат, который позволял бы передать только четыре точки в одинарной СМСке, когда весь трек состоит из десятков (в некоторых случаях — из сотен) точек. К сожалению, мы пережили то время, когда программирование было искусством.
Тут можно отметить две вещи:
1. Нужно не забывать правильно очищать входные байты, которые «шарятся» между полями сообщения (пример с первым байтом при декодировании поля dateTime).
2. Используется Big Endian порядок байтов (замечание актуально только для платформ/языков, где используется другой порядок), так как от «расшаренных» байтов под флаги откусываются старшие биты старших байтов.
В предыдущем комментарии конечно же имелся ввиду «скриншот».
Впрочем, пока писал статью — увидел ещё несколько возможных вариантов допущений и оптимизаций, но уж как было — так и рассказал.