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

Теперь же в it ломанулся поток. 500+ откликов на джунскую вакансию с завышенными требованиями и заниженной зп - вот именно от этого. Куча народу мечтает о золотых горах, но, часто даже близко не имеет нужных знаний и навыков. Программист уже не может обработать эти 500 откликов, как когда-то обрабатывал 2 в месяц, он вынужденно передает это hr. Ну а hr, очевидно, вносит определенный эффект сломанного телефона, когда толковые ребята начинают тоже до собеса не доходить.

В целом, мы наблюдаем классическую ситуацию дисбаланса спрос/предложение. Спрос на вакансии со стороны джунов вырос кратно больше, чем предложение со стороны работодателей. Все прочее - просто естественное неизбежное следствие. И проблема имеет 2 решения: снижение зп в отрасли до близких к средним, либо повышение средних к уровню it

Понятно, что выше приведен сатиричный и гиперболизированный пример.

Ощущаю себя примерно так после тех 4 замечательных жизненных примеров. Разве что каноничного "Привет" без продолжения не хватает

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 ячеек мерять, абсурдно бессмысленно

Возникло несколько вопросов.

1. setSourceRectHint(sourceRectHint) - границы контента, который будет виден во время перехода в PiP-mode - вот тут я не понял, что имеется в виду и в каком формате передается

2. В ограничениях есть указание, что Picture in Picture (PiP) mode появился в android 8.0 (api level 26). Дальше по тексту для выхода из PiP мода приведены примеры кода до 5 андроида и после. Получается какое-то противоречие:)

P.s. Это работает только для 1 ошибки, для исправления двух ошибок лучше использовать какой-нибудь более сложный способ

1. В статье нет псевдокода других решений, здесь есть вот это:

   ЦИКЛ по символам всей строки:
ЦИКЛ по всем длинам, начиная с текущего символа:
ЦИКЛ по символам в этой подстроке:

   Для человека, который не писал сравнительно недавно этот алгоритм и не занимается им постоянно, это не даёт вообще никакой информации.

2. Вы, кажется, вообще не поняли мой второй пункт, судя по Вашему ответу. Моя претензия ровно в том, что Вы используете обфусцированный олимпиадный стиль. Даже специально на русскую википедию заглянул. простите, отличий в стиле я не вижу, всё также вырвиглазно. Кажется, практически всё сообщество программистов уже очень давно пришло к пониманию того, что олимпиадный стиль - чудовищно плохой. И подходит только и исключительно для олимпиад и быстрого (в пределах часов) прототипирования. И уж точно такой стиль никак не подходит для публикаций. Прошу простить мою резкость, но с самых университетских времён каждый грёбаный преподаватель и автор книг/статей на русском языке считает своим долгом заставить читателя самостоятельно разбираться, что и какая буковка в коде обозначает, в итоге 3/4 времени тратится не на понимание алгоритма, а на понимание смысла однобуквенных переменных автора. И да, английская википедия - отличный пример как надо делать.

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

P.s. Замечу, что даже при отсутствии данных вещей в оригинале, имело немалый смысл добавить их при переводе как ремарки.

не перегревайте рынок

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

Ага, я понял, старайтесь быть как можно более добрым и жестоким!

Или это уже немного другое?

Это совершенно другое. Если бы Марс был:

1. Полон наиболее ценных на данный момент ресурсов (редкоземельные металлы, нефтеподобные ресурсы для производства пластиков и прочее).
   
   В общей сумме ценность минералов должна быть такая, чтобы отправив туда 5 кораблей и потеряв 3 по пути (причем один из 2 оставшихся вернув без груза) можно было получить чистую прибыль, сравнимую со стоимостью отправки всей экспедиции. (путешествие Магеллана - яркий пример)

2. Подходящим для постоянного проживания лучше Земли

То вот тогда это было бы что-то сравнимое с освоением Америки. Увы, Марс по сути бесполезен в перпективе ближайших нескольких столетий

P.s.

> Есть вопрос про подгузку данных. Как вы думаете, насколько необходимо ее осуществлять при работе с БД на устройстве?

Зависит от того, что лежит в БД. Во-первых структура может быть сложной и тянущей данные со множества таблиц, тогда загрузка всех данных может занимать вплоть до минут, что непозволительно долго. Во-вторых, данных могут быть десятки тысяч строк, тогда даже сравнительно простая структура будет тянуться уже не мгновенно.

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

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