Снижение зарплаты решит проблему, обсуждаемую в статье (очевидно, это также нанесет катастрофический ущерб отрасли)
Я скорее говорил о том, что обсуждаемая в статье проблема фундаментальна и создана ситуацией на рынке, а не глупыми менеджерскими решениями / трендами найма / жадностью бизнеса или еще чем-то.
Имхо, в статье упущен важнейший компонент - престижность профессии. Раньше джунами приходили в основном реально интересующиеся люди, часто текущие студенты, притом и проактивные (забивальщики на учебу и работу по профессии особо не ищут обычно). При потоке 1-2 человека в месяц желающих из которых 50% можно взять к себе джуном, разумеется любой опытный разработчик согласится пообщаться просто вживую. И, обычно, этого общения хватит, чтобы понять, свой ли человек пришел, можно ли брать. Но так было в нулевых.
Теперь же в it ломанулся поток. 500+ откликов на джунскую вакансию с завышенными требованиями и заниженной зп - вот именно от этого. Куча народу мечтает о золотых горах, но, часто даже близко не имеет нужных знаний и навыков. Программист уже не может обработать эти 500 откликов, как когда-то обрабатывал 2 в месяц, он вынужденно передает это hr. Ну а hr, очевидно, вносит определенный эффект сломанного телефона, когда толковые ребята начинают тоже до собеса не доходить.
В целом, мы наблюдаем классическую ситуацию дисбаланса спрос/предложение. Спрос на вакансии со стороны джунов вырос кратно больше, чем предложение со стороны работодателей. Все прочее - просто естественное неизбежное следствие. И проблема имеет 2 решения: снижение зп в отрасли до близких к средним, либо повышение средних к уровню it
In this test, the framework's ORM is used to fetch all rows from a database table containing an unknown number of Unix fortune cookie messages (the table has 12 rows, but the code cannot have foreknowledge of the table's size).
Серьезно? Бенчмарк фреймворков для работы с сетью и ORM на таблице с 12 строками (~2 Кб)? Это не просто синтетическая задача, это как производительность алгоритмов сортировки на массивах в 12 ячеек мерять, абсурдно бессмысленно
setSourceRectHint(sourceRectHint) - границы контента, который будет виден во время перехода в PiP-mode - вот тут я не понял, что имеется в виду и в каком формате передается
В ограничениях есть указание, что Picture in Picture (PiP) mode появился в android 8.0 (api level 26). Дальше по тексту для выхода из PiP мода приведены примеры кода до 5 андроида и после. Получается какое-то противоречие:)
И там всё же не было ответа на главный вопрос - почему не Марс? Ну и вероятность того, что жизнь с другой звездной системы вообще будет способна к комфортной жизни в земных условиях просто смехотворна, куда безопаснее, дешевле и быстрее космические станции на орбите или соседних безжизненных планетах с постепенной терраформацией. Иначе может получиться как в Войне Миров, но инопланетяне же не тупые)
Вот только 100к сейчас даже в регионах уже для разработчика с опытом в год-полтора зарплата низковатая. В Москве (на удаленке, продолжая жить в регионе) человек с опытом в 3+ года легко и не напрягаясь находит зарплату в 200+ и (постаравшись) в 300+
Я бы попробовал поменять все буквы слова на все возможные символы и сделать для каждого варианта запрос в словарь на полное совпадение.
Если работаем с кириллицей, то это 32 * L запросов в словарь на полное совпадение, где L - длина слова (почти всегда будет не более 15). Интуитивно кажется, что даже однократное вычисление расстояния Левенштейна для двух слов будет в среднем несколько дольше, чем такой перебор.
P.s. Это работает только для 1 ошибки, для исправления двух ошибок лучше использовать какой-нибудь более сложный способ
Вот только в статье описан ровно один кейс - собственно сдача "биометрии". Если Ваша биометрия уже сдана в банке, то этот же банк таким способом точно не взломают. А вот как раз если Вы в банк биометрию НЕ сдали, то туда можно отправить чужую биометрию (паспортные данные еще нужны, но их добыть вообще не проблема).
На всякий случай, в чем именно заключается взлом из статьи: Когда кто-то (условный банк) просит подтвердить личность, не имея на руках биометрию, то могут либо потребовать лично явиться в офис, либо сэкономить время и попросить снять себя на видео с паспортом в руках. Как раз при съемке видео с паспортом можно использовать дипфейк (паспорт изначально берется идентичный реальному, но с наложенным чужим фото).
Если я правильно понял, то Вы автор оригинала. Так вот,
В статье нет псевдокода других решений, здесь есть вот это:
ЦИКЛ по символам всей строки: ЦИКЛ по всем длинам, начиная с текущего символа: ЦИКЛ по символам в этой подстроке:
Для человека, который не писал сравнительно недавно этот алгоритм и не занимается им постоянно, это не даёт вообще никакой информации.
Вы, кажется, вообще не поняли мой второй пункт, судя по Вашему ответу. Моя претензия ровно в том, что Вы используете обфусцированный олимпиадный стиль. Даже специально на русскую википедию заглянул. простите, отличий в стиле я не вижу, всё также вырвиглазно. Кажется, практически всё сообщество программистов уже очень давно пришло к пониманию того, что олимпиадный стиль - чудовищно плохой. И подходит только и исключительно для олимпиад и быстрого (в пределах часов) прототипирования. И уж точно такой стиль никак не подходит для публикаций. Прошу простить мою резкость, но с самых университетских времён каждый грёбаный преподаватель и автор книг/статей на русском языке считает своим долгом заставить читателя самостоятельно разбираться, что и какая буковка в коде обозначает, в итоге 3/4 времени тратится не на понимание алгоритма, а на понимание смысла однобуквенных переменных автора. И да, английская википедия - отличный пример как надо делать.
Ещё раз простите за резкость, боюсь, это Вас задело. Это просто очень наболевшее. Как очереди в поликлиниках и мфц. Надеюсь, Вы примете к сведению, что для восприятия со стороны ученика/читателя однобуквенный олимпиадный стиль чрезвычайно неудобен.
По поводу перевода статей - возможно, это уже Вы исправили, но в шапке есть ссылка на Вашу оригинальную статью. Если изначально этой ссылки не было - искренне присоединяюсь к осуждению переводчика
Статье отчаянно не хватает двух вещей: 1. Код для наивного и промежуточного решений. Они описаны так, что не решавший задачу человек вынужден будет её практически решать при чтении в уме. 2. Нормальных наименований в коде. Я понимаю, что код писался в олимпиадном стиле, когда почти все переменные однобуквенные, но выкладывать такой код в статье - позор.
P.s. Замечу, что даже при отсутствии данных вещей в оригинале, имело немалый смысл добавить их при переводе как ремарки.
Мне кажется куда более логичным вариант с пятидневкой по 6 часов. Эффективных рабочих часов будет больше, чем при четырехдневке, а отдыха по факту сотрудникам достанется не меньше.
Поясню. Сотрудник, работающий в классическую пятидневку имеет следующие времязатраты: 1. Сон. 8 часов, или будет падать эффективность работы. 2. Работа. 8 часов. Всё по ТК 3. Обед в середине дня. 1 час 4. Завтрак + ужин + приготовление пищи. Еще 1.5 часа 5. Душ / умывание / домашние дела по мелочи. Еще 1 час 6. Дорога до/с работы. 1-2 часа, зависит от места жительства, может быть и меньше, но в крупных городах меньше часа на дорогу суммарно редко выходит. Сумма: 20.5 - 21.5 часов То есть в сутки на отдых и личное время реально остается 2.5 - 3.5 часа. Уменьшение рабочего времени с 8 до 6 часов почти удвоит ежедневное время отдыха для огромного числа людей! И увеличит как минимум в 1.5 раза вообще для всех за редким исключением.
Ну а если еще вспомнить, что продуктивной работы реально больше 4 часов почти не бывает, то скорее всего и результат труда мало изменится.
Это по всем специализациям (devops, аналитики, QA, дизайнеры и зачастую менеджмент получают меньше разработчиков) Это по всем уровням квалификации (джунов и только что вошедших в специальность стабильно много, причем чуть ли не половина отсеивается в первые пол года-год) Даже при всех этих условиях 10% получают 300к и более. Если брать только разработчиков и только 3+ года опыта, то окажется, что не 10%, а все 30-40. А для 5+лет опыта и вовсе ближе к 50% будет доля получающих 300к+
Как показывает мой личный опыт, С++ это код, который пишется в 3 раза дольше, имеет в 3 раза больше багов и работает в 1.5 раза быстрее, чем Java 1.8. Зная ЗП разработчиков, дешевле купить чуть больше железа.
Есть отдельные задачи, где эффективность куда выше конечно, но тут лучше написать на плюсах маленький кусочек и встроить через JNI в java, чем вообще все на плюсах хреначить.
На самом деле очень даже пришлось корабли дорабатывать, просто это процесс начался еще с попыток доплыть в Индию вокруг Африки, но подготовка к плаванию Колумба только закончилась и в дальнейшем активно шла
Полон наиболее ценных на данный момент ресурсов (редкоземельные металлы, нефтеподобные ресурсы для производства пластиков и прочее).
В общей сумме ценность минералов должна быть такая, чтобы отправив туда 5 кораблей и потеряв 3 по пути (причем один из 2 оставшихся вернув без груза) можно было получить чистую прибыль, сравнимую со стоимостью отправки всей экспедиции. (путешествие Магеллана - яркий пример)
Подходящим для постоянного проживания лучше Земли
То вот тогда это было бы что-то сравнимое с освоением Америки. Увы, Марс по сути бесполезен в перпективе ближайших нескольких столетий
Если честно, тщательно даже читать статью не стал - вероятность того, что Вы изобрели что-то лучше просто ничтожна. И почти уверен, что просмотрев видео Вы найдете у себя в реализации по крайней мере 1 существенный недостаток, а скорее всего - больше.
В любом случае, спасибо, что поделились, другим новичкам может серьезно помочь)
P.s.
> Есть вопрос про подгузку данных. Как вы думаете, насколько необходимо ее осуществлять при работе с БД на устройстве?
Зависит от того, что лежит в БД. Во-первых структура может быть сложной и тянущей данные со множества таблиц, тогда загрузка всех данных может занимать вплоть до минут, что непозволительно долго. Во-вторых, данных могут быть десятки тысяч строк, тогда даже сравнительно простая структура будет тянуться уже не мгновенно.
Среди тысяч откликов на топовую вакансию не будет ни одного искомого HRом (за очень редким исключением). Сециалист, подходящий на топовую вакансию, уже сидит на аналогичном месте в другой компании. Ему нафиг не надо ходить отклики рассылать, ему другие HRы по десять офферов (зачастую, написанных персонально под него) в неделю в личку шлют.
Дело не в том. что специалистов слишком много и сложно выбирать. Дело в том, что вы морскую рыбу сетью ловите... в пресноводной реке, впадающей в озеро. И при этом считаете проблемой, что непонятно, как её (морскую рыбу) в случае поимки от пресноводной рыбы отличать, тогда как проблема, очевидно, в месте и способе ловли.
Снижение зарплаты решит проблему, обсуждаемую в статье (очевидно, это также нанесет катастрофический ущерб отрасли)
Я скорее говорил о том, что обсуждаемая в статье проблема фундаментальна и создана ситуацией на рынке, а не глупыми менеджерскими решениями / трендами найма / жадностью бизнеса или еще чем-то.
Имхо, в статье упущен важнейший компонент - престижность профессии. Раньше джунами приходили в основном реально интересующиеся люди, часто текущие студенты, притом и проактивные (забивальщики на учебу и работу по профессии особо не ищут обычно). При потоке 1-2 человека в месяц желающих из которых 50% можно взять к себе джуном, разумеется любой опытный разработчик согласится пообщаться просто вживую. И, обычно, этого общения хватит, чтобы понять, свой ли человек пришел, можно ли брать. Но так было в нулевых.
Теперь же в it ломанулся поток. 500+ откликов на джунскую вакансию с завышенными требованиями и заниженной зп - вот именно от этого. Куча народу мечтает о золотых горах, но, часто даже близко не имеет нужных знаний и навыков. Программист уже не может обработать эти 500 откликов, как когда-то обрабатывал 2 в месяц, он вынужденно передает это hr. Ну а hr, очевидно, вносит определенный эффект сломанного телефона, когда толковые ребята начинают тоже до собеса не доходить.
В целом, мы наблюдаем классическую ситуацию дисбаланса спрос/предложение. Спрос на вакансии со стороны джунов вырос кратно больше, чем предложение со стороны работодателей. Все прочее - просто естественное неизбежное следствие. И проблема имеет 2 решения: снижение зп в отрасли до близких к средним, либо повышение средних к уровню it
Ощущаю себя примерно так после тех 4 замечательных жизненных примеров. Разве что каноничного "Привет" без продолжения не хватает
Серьезно? Бенчмарк фреймворков для работы с сетью и ORM на таблице с 12 строками (~2 Кб)?
Это не просто синтетическая задача, это как производительность алгоритмов сортировки на массивах в 12 ячеек мерять, абсурдно бессмысленно
Большое спасибо за статью!
Возникло несколько вопросов.
setSourceRectHint(sourceRectHint) - границы контента, который будет виден во время перехода в PiP-mode - вот тут я не понял, что имеется в виду и в каком формате передается
В ограничениях есть указание, что Picture in Picture (PiP) mode появился в android 8.0 (api level 26). Дальше по тексту для выхода из PiP мода приведены примеры кода до 5 андроида и после. Получается какое-то противоречие:)
И там всё же не было ответа на главный вопрос - почему не Марс?
Ну и вероятность того, что жизнь с другой звездной системы вообще будет способна к комфортной жизни в земных условиях просто смехотворна, куда безопаснее, дешевле и быстрее космические станции на орбите или соседних безжизненных планетах с постепенной терраформацией.
Иначе может получиться как в Войне Миров, но инопланетяне же не тупые)
Вот только 100к сейчас даже в регионах уже для разработчика с опытом в год-полтора зарплата низковатая.
В Москве (на удаленке, продолжая жить в регионе) человек с опытом в 3+ года легко и не напрягаясь находит зарплату в 200+ и (постаравшись) в 300+
Я бы попробовал поменять все буквы слова на все возможные символы и сделать для каждого варианта запрос в словарь на полное совпадение.
Если работаем с кириллицей, то это 32 * L запросов в словарь на полное совпадение, где L - длина слова (почти всегда будет не более 15). Интуитивно кажется, что даже однократное вычисление расстояния Левенштейна для двух слов будет в среднем несколько дольше, чем такой перебор.
P.s. Это работает только для 1 ошибки, для исправления двух ошибок лучше использовать какой-нибудь более сложный способ
Вот только в статье описан ровно один кейс - собственно сдача "биометрии". Если Ваша биометрия уже сдана в банке, то этот же банк таким способом точно не взломают. А вот как раз если Вы в банк биометрию НЕ сдали, то туда можно отправить чужую биометрию (паспортные данные еще нужны, но их добыть вообще не проблема).
На всякий случай, в чем именно заключается взлом из статьи:
Когда кто-то (условный банк) просит подтвердить личность, не имея на руках биометрию, то могут либо потребовать лично явиться в офис, либо сэкономить время и попросить снять себя на видео с паспортом в руках. Как раз при съемке видео с паспортом можно использовать дипфейк (паспорт изначально берется идентичный реальному, но с наложенным чужим фото).
Если я правильно понял, то Вы автор оригинала.
Так вот,
В статье нет псевдокода других решений, здесь есть вот это:
ЦИКЛ по символам всей строки:ЦИКЛ по всем длинам, начиная с текущего символа:
ЦИКЛ по символам в этой подстроке:
Для человека, который не писал сравнительно недавно этот алгоритм и не занимается им постоянно, это не даёт вообще никакой информации.
Вы, кажется, вообще не поняли мой второй пункт, судя по Вашему ответу. Моя претензия ровно в том, что Вы используете обфусцированный олимпиадный стиль. Даже специально на русскую википедию заглянул. простите, отличий в стиле я не вижу, всё также вырвиглазно. Кажется, практически всё сообщество программистов уже очень давно пришло к пониманию того, что олимпиадный стиль - чудовищно плохой. И подходит только и исключительно для олимпиад и быстрого (в пределах часов) прототипирования. И уж точно такой стиль никак не подходит для публикаций. Прошу простить мою резкость, но с самых университетских времён каждый грёбаный преподаватель и автор книг/статей на русском языке считает своим долгом заставить читателя самостоятельно разбираться, что и какая буковка в коде обозначает, в итоге 3/4 времени тратится не на понимание алгоритма, а на понимание смысла однобуквенных переменных автора. И да, английская википедия - отличный пример как надо делать.
Ещё раз простите за резкость, боюсь, это Вас задело. Это просто очень наболевшее. Как очереди в поликлиниках и мфц. Надеюсь, Вы примете к сведению, что для восприятия со стороны ученика/читателя однобуквенный олимпиадный стиль чрезвычайно неудобен.
По поводу перевода статей - возможно, это уже Вы исправили, но в шапке есть ссылка на Вашу оригинальную статью. Если изначально этой ссылки не было - искренне присоединяюсь к осуждению переводчика
Статье отчаянно не хватает двух вещей:
1. Код для наивного и промежуточного решений. Они описаны так, что не решавший задачу человек вынужден будет её практически решать при чтении в уме.
2. Нормальных наименований в коде. Я понимаю, что код писался в олимпиадном стиле, когда почти все переменные однобуквенные, но выкладывать такой код в статье - позор.
P.s. Замечу, что даже при отсутствии данных вещей в оригинале, имело немалый смысл добавить их при переводе как ремарки.
Мне кажется куда более логичным вариант с пятидневкой по 6 часов. Эффективных рабочих часов будет больше, чем при четырехдневке, а отдыха по факту сотрудникам достанется не меньше.
Поясню.
Сотрудник, работающий в классическую пятидневку имеет следующие времязатраты:
1. Сон. 8 часов, или будет падать эффективность работы.
2. Работа. 8 часов. Всё по ТК
3. Обед в середине дня. 1 час
4. Завтрак + ужин + приготовление пищи. Еще 1.5 часа
5. Душ / умывание / домашние дела по мелочи. Еще 1 час
6. Дорога до/с работы. 1-2 часа, зависит от места жительства, может быть и меньше, но в крупных городах меньше часа на дорогу суммарно редко выходит.
Сумма: 20.5 - 21.5 часов
То есть в сутки на отдых и личное время реально остается 2.5 - 3.5 часа.
Уменьшение рабочего времени с 8 до 6 часов почти удвоит ежедневное время отдыха для огромного числа людей! И увеличит как минимум в 1.5 раза вообще для всех за редким исключением.
Ну а если еще вспомнить, что продуктивной работы реально больше 4 часов почти не бывает, то скорее всего и результат труда мало изменится.
Это по всем специализациям (devops, аналитики, QA, дизайнеры и зачастую менеджмент получают меньше разработчиков)
Это по всем уровням квалификации (джунов и только что вошедших в специальность стабильно много, причем чуть ли не половина отсеивается в первые пол года-год)
Даже при всех этих условиях 10% получают 300к и более.
Если брать только разработчиков и только 3+ года опыта, то окажется, что не 10%, а все 30-40. А для 5+лет опыта и вовсе ближе к 50% будет доля получающих 300к+
Как показывает мой личный опыт, С++ это код, который пишется в 3 раза дольше, имеет в 3 раза больше багов и работает в 1.5 раза быстрее, чем Java 1.8. Зная ЗП разработчиков, дешевле купить чуть больше железа.
Есть отдельные задачи, где эффективность куда выше конечно, но тут лучше написать на плюсах маленький кусочек и встроить через JNI в java, чем вообще все на плюсах хреначить.
Ага, я понял, старайтесь быть как можно более добрым и жестоким!
На самом деле очень даже пришлось корабли дорабатывать, просто это процесс начался еще с попыток доплыть в Индию вокруг Африки, но подготовка к плаванию Колумба только закончилась и в дальнейшем активно шла
Это совершенно другое. Если бы Марс был:
Полон наиболее ценных на данный момент ресурсов (редкоземельные металлы, нефтеподобные ресурсы для производства пластиков и прочее).
В общей сумме ценность минералов должна быть такая, чтобы отправив туда 5 кораблей и потеряв 3 по пути (причем один из 2 оставшихся вернув без груза) можно было получить чистую прибыль, сравнимую со стоимостью отправки всей экспедиции. (путешествие Магеллана - яркий пример)
Подходящим для постоянного проживания лучше Земли
То вот тогда это было бы что-то сравнимое с освоением Америки. Увы, Марс по сути бесполезен в перпективе ближайших нескольких столетий
Беглый гуглеж говорит о том, что 30 млрд - именно выручка, а чистая прибыль составила чуть больше 5 млрд за год.
Вот здесь есть замечательное видео на тему от профессионалов.
https://www.youtube.com/watch?v=g7wwybnXE40
Если честно, тщательно даже читать статью не стал - вероятность того, что Вы изобрели что-то лучше просто ничтожна. И почти уверен, что просмотрев видео Вы найдете у себя в реализации по крайней мере 1 существенный недостаток, а скорее всего - больше.
В любом случае, спасибо, что поделились, другим новичкам может серьезно помочь)
P.s.
> Есть вопрос про подгузку данных. Как вы думаете, насколько необходимо ее осуществлять при работе с БД на устройстве?
Зависит от того, что лежит в БД. Во-первых структура может быть сложной и тянущей данные со множества таблиц, тогда загрузка всех данных может занимать вплоть до минут, что непозволительно долго. Во-вторых, данных могут быть десятки тысяч строк, тогда даже сравнительно простая структура будет тянуться уже не мгновенно.
Вы, кажется, упускаете суть.
Среди тысяч откликов на топовую вакансию не будет ни одного искомого HRом (за очень редким исключением). Сециалист, подходящий на топовую вакансию, уже сидит на аналогичном месте в другой компании. Ему нафиг не надо ходить отклики рассылать, ему другие HRы по десять офферов (зачастую, написанных персонально под него) в неделю в личку шлют.
Дело не в том. что специалистов слишком много и сложно выбирать. Дело в том, что вы морскую рыбу сетью ловите... в пресноводной реке, впадающей в озеро. И при этом считаете проблемой, что непонятно, как её (морскую рыбу) в случае поимки от пресноводной рыбы отличать, тогда как проблема, очевидно, в месте и способе ловли.