Да, социального аспекта было минимум. Первое время было буквально сложно общаться с людьми: я не мог расслышать что они говорят своими приглушёнными голосами. Думаю, это была проблема не с остротой слуха, а с повреждением процесса обработки звукового сигнала мозгом. Потом всё восстановилось. Ваш комментарий напомнил истории про некоторых аутистов, у которых социальный план минимален, зато выдающиеся способности например в математике. Хотя у меня ничего выдающегося не было, просто такое странное смещение.
программисты способны пару дней работать по 12 часов, выдавая что-то средненькое в больших количествах. Потом могут и дальше сидеть по 12 часов но эффективность будет никакая. Потом отходят после этого от трех дней до недели и больше.
Один раз я в течение месяца работал по 20 часов в день абсолютно не уставая. Это было когда я шёл на поправку после тяжелой формы ковида. То ли последствия самого коронавируса, то ли сайд-эффект от лечения. Спал я 2-3 часа в сутки, и мне этого полностью хватало, я просыпался абсолютно бодрым и не знал как уснуть дальше, за сутки усталости так и не появлялось. Я был тогда в слишком странном состоянии для общения или каких-либо повседневных задач, а кодить получалось хорошо: не было проблем с дефицитом внимания, я вообще ни на что не отвлекался и мне вообще ничего кроме текущей задачи не было интересно. Был такой машиной по закрытию тасков. Такой вечный поток. Я был предельно эффективен, но рад что этот период закончился.
Я к тому, что мозг может работать порой в очень необычных режимах, и мы внутри своего контекста даже не представляем что может быть по-другому. Я вполне допускаю, что автор статьи за счёт жёсткого режима натаскал мозг эффективно работать над его типом задач. Тема с тем что работа — это далеко не всегда поток в статье конечно осталась открытой.
Я в таком режиме живу 8 лет. Бизнес пока вроде бы не умер, и до сих пор растёт как ни странно, хотя единичный пример не статистика. Но я всё-таки надеюсь что я провожу всё свободное время за проектом потому что это мой проект, а не потому что я по-другому не умею, и работа для меня — просто форма эскапизма от более сложной и непонятной реальной жизни.
В принципе более-менее понятно почему API в таком виде.
RESTful API — не могу сказать что это общепринятый стандарт. Порой необходимый функционал натянуть на GET/POST/PUT/DELETE — весьма нетривиальная задача.
Использование snake case не должно смущать, это стандарт основной библиотеки PHP. Несмотря на то, что сейчас в основном методы и т.д. пишутся в camelCase — то что был выбран snake_case для API — ничего удивительного. Несоответствие с заглавными буквами пожалуй тоже понимаю откуда взялось: скорее всего значения в корне прописаны программно, а значения с заглавными буквами — это какой-то select из базы, и там поля хранятся именно так.
Различный тип для числа (string и int) — PHP-шники до недавнего времени не особо запаривались с типами.
Если спец по бэкэнду работает в вашей же команде — решить вопросы с int, возвращением заголовка application/json и т.д. — это должно быть просто. Если же вы работаете с внешним API — то ожидать от него любой дичи даже если на первый взгляд всё выглядит хорошо — абсолютно нормально. Гораздо меньше шансов, что какое-то не то значение сломает ваше приложение.
Иногда рекрутёры сами упрощают такую задачу. Из недавнего присланного мне письма по поводу работы:
Если не попала в зону ваших интересов, то я была бы рада получить фидбек. Можно просто поставить букву :)
а) Я сейчас не рассматриваю никаких, даже самых чудесных вакансий. На текущем месте все более чем устраивает!
б) Не попали с предложением, у меня другой стек/уровень/сфера интересов.
в) Мало денег.
г) Не интересны задачи/компания
д) Другое
Как рекрутёры меня находят — другой вопрос, последние лет 10 я не оставлял резюме и не искал работу, да и то резюме 10-летней давности провисело хорошо если неделю.
Иногда такое может быть из-за того, что на рынке перекос в пользу соискателей. Я не про совсем нерелевантные звонки, а частично нерелевантные конечно. Пример: ищем программиста, точно знаем чего мы хотим. Проходит месяц, до собеседования доходит 0 человек. Приходится расширять список подходящих резюме: тааак, если он этого не знает — наверное не страшно, этому мы и сами можем обучить, и т.д. HR-ы сперва слишком вольно понимают ослабление требований и пытаются связаться с совсем уж нерелевантными кандидатами (например, на вакансию фуллстека начинают звать 100% франтендов, но это не удивительно, рекрутёры не являются спецами по IT). После пачки таких резюме — HR-ов приходится калибровать. Но всё равно приходится связываться с кандидатами, по поводу которых знаешь что скорее всего друг другу не подойдём, в надежде что всё-таки чудо случится, что он чего-то просто не указал в резюме.
Если ты Яндекс — ты можешь мучить кандидатов алгоритмическими задачами, и поток желающих всё равно будет. А если ты маленькая контора на 10 человек, при этом не мегабогатая, чтобы перебивать всех уровнем ЗП, поиск программистов становится очень непростым делом.
Так обратной совместимости уже давно нет. В каждом ежегодном релизе PHP ещё со времён PHP 5 есть ломающие изменения. У меня есть проекты застрявшие кажется на PHP 5.3, потому что они больше не развиваются, а выделять отдельно время на их переписывание не хочется.
Другое дело, что изменения довольно минимальны, и если вы с самого начала писали код качественно, не увлекаясь например преобразованием строк типа «abc» в int и не пытаясь получить $foo['bar'] где $foo === null, есть шанс что вы их вообще не заметите.
А вот перенос стандартной библиотеки на неймспейсы повлияет на каждую программу. И здесь двояко: с одной стороны изменения очевидные, и достаточно пройтись по коду автоматическим инструментом чтобы всё поменять, с другой стороны я такое буду делать только на живых проектах, это всё равно работа.
Плюс библиотеки в Composer. При обновлении с PHP 7.4 на PHP 8 например минимум 90% из них будут работать без изменений. А при предложенном автором изменении сломается каждая вторая из них, если не каждая первая. И сколько времени потребуется на их обновление?
В идеальном мире я бы вообще отказался от стандартных функций работы со строками, массивами и т.д. и преобразовал бы такие сущности в объекты, как уже давным-давно сделано во множестве других языков.
По поводу выпиливания текущей реализации стандартной библиотеки сложно, так как она используется очень часто. Процент кода, на который это повлияет будет сильно больше, чем у предыдущих ломающих изменений PHP. Функции будет довольно просто заменить чем-нибудь типа Rector, но руками это будет нереально.
При этом сервисы Яндекса и так регулярно падают. В Яндекс.коннект или в метрике или в Яндекс Недвижимости регулярно натыкаюсь на «ваш запрос не может быть выполнен», на несохранение каких-либо действий или просто на неверную выдачу.
Массово — нет. Тем более что далеко не у всех VPN хорошо со скоростью настолько, что можно смотреть видео. А дальше, в случае успешной работы стратегии «замедления» происходит примерно следующее: юзер-экспириенс по посещению замедленных сайтов упадёт, при наличие нетормозящей альтернативы, люди будут постепенно перетекать на эту альтернативу. С условного ФБ на условный ВК. И как властям скорее всего очень хочется — с Ютьюба на какую-нибудь более подконтрольную платформу. Когда перетечёт больше N% аудитории — зарубежный сервис можно блочить совсем, сильных возмущений по поводу уже непопулярного сервиса не будет.
Т.е. даже если персонально вам VPN поможет, то друзей и знакомых в замедленной или заблоченной социальной сети всё равно будет становиться всё меньше и меньше.
Однако ситуация всё-таки меняется. До 2021 года Вконтакте не блокировал группы по митингам, в 2021 году — заблокировал почти все. Не говоря уже что в принципе в соцсетях писать про митинги стало опаснее. Сейчас так, но я не стал бы утверждать, что власти никогда не пойдут на блокировку Ютьюба. Общество к такому готовится постепенно.
Лягушка потихоньку варится. Ещё не так давно такое бы повлекло большие последствия. Жемчужный прапорщик, который в том же Питере в 2010 году «схватил протестующего за волосы и нанёс удар по голове дубинкой» получил 3,5 года условно, в то время эта история вызвала большой резонанс. Теперь ОМОНу ничего не бывает и за куда более вопиющие случаи.
Всё-таки изначальные разработчики стандартов вряд ли могли подумать, что веб станет тем, чем стал. Сложные приложения писались для веба изначально не потому, что это javascript+html+css — идеальная платформа для этого, а потому что это путь для использования широкой аудиторией. Сперва костыляли на том, что есть, потом вводили стандарты.
Но из-за обязательной обратной совместимости (в том числе по отношению даже к странным и глючным решениям) нельзя просто отрефакторить какой-то метод API. Однажды сделанное неоптимальное решение остаётся в вебе навсегда. Неудобно? Делаем новый стандарт. Вёрстка на таблицах не катит? Верстаем на дивах. Неудобно? Flexbox. Всё равно неудобно? Grid. Какие-то api забрасываются, разрабатываются новые с похожим функционалом. И весь этот легаси надо поддерживать.
Возможно именно такой возраст Вселенной наиболее благоприятен для появления жизни. В дальнейшем скорость звездообразования будет падать, планеты у долгоживущих красных карликов будут терять атмосферу и т.д. Да, Вселенная будет существовать ещё триллионы лет, но это будет не та же самая Вселенная.
Просто ниша животных уже занята животными, для возникновения нервной системы им нужно преодолеть слишком большой порог. Это как сделать второй фэйсбук, когда уже есть фэйсбук. Но если бы все животные внезапно исчезли — возможно спустя какое-то (всё равно длительное) время, часть растений обрела бы и нервную систему и прочее.
Один раз я в течение месяца работал по 20 часов в день абсолютно не уставая. Это было когда я шёл на поправку после тяжелой формы ковида. То ли последствия самого коронавируса, то ли сайд-эффект от лечения. Спал я 2-3 часа в сутки, и мне этого полностью хватало, я просыпался абсолютно бодрым и не знал как уснуть дальше, за сутки усталости так и не появлялось. Я был тогда в слишком странном состоянии для общения или каких-либо повседневных задач, а кодить получалось хорошо: не было проблем с дефицитом внимания, я вообще ни на что не отвлекался и мне вообще ничего кроме текущей задачи не было интересно. Был такой машиной по закрытию тасков. Такой вечный поток. Я был предельно эффективен, но рад что этот период закончился.
Я к тому, что мозг может работать порой в очень необычных режимах, и мы внутри своего контекста даже не представляем что может быть по-другому. Я вполне допускаю, что автор статьи за счёт жёсткого режима натаскал мозг эффективно работать над его типом задач. Тема с тем что работа — это далеко не всегда поток в статье конечно осталась открытой.
RESTful API — не могу сказать что это общепринятый стандарт. Порой необходимый функционал натянуть на GET/POST/PUT/DELETE — весьма нетривиальная задача.
Использование snake case не должно смущать, это стандарт основной библиотеки PHP. Несмотря на то, что сейчас в основном методы и т.д. пишутся в camelCase — то что был выбран snake_case для API — ничего удивительного. Несоответствие с заглавными буквами пожалуй тоже понимаю откуда взялось: скорее всего значения в корне прописаны программно, а значения с заглавными буквами — это какой-то select из базы, и там поля хранятся именно так.
Различный тип для числа (string и int) — PHP-шники до недавнего времени не особо запаривались с типами.
Если спец по бэкэнду работает в вашей же команде — решить вопросы с int, возвращением заголовка application/json и т.д. — это должно быть просто. Если же вы работаете с внешним API — то ожидать от него любой дичи даже если на первый взгляд всё выглядит хорошо — абсолютно нормально. Гораздо меньше шансов, что какое-то не то значение сломает ваше приложение.
Как рекрутёры меня находят — другой вопрос, последние лет 10 я не оставлял резюме и не искал работу, да и то резюме 10-летней давности провисело хорошо если неделю.
Если ты Яндекс — ты можешь мучить кандидатов алгоритмическими задачами, и поток желающих всё равно будет. А если ты маленькая контора на 10 человек, при этом не мегабогатая, чтобы перебивать всех уровнем ЗП, поиск программистов становится очень непростым делом.
u('FOO Bar')->lower();всё же не то же самое, что и'FOO Bar'->lower();. Хотя да, фреймворки делают работу со строками/массивами удобнее.Другое дело, что изменения довольно минимальны, и если вы с самого начала писали код качественно, не увлекаясь например преобразованием строк типа «abc» в int и не пытаясь получить $foo['bar'] где $foo === null, есть шанс что вы их вообще не заметите.
А вот перенос стандартной библиотеки на неймспейсы повлияет на каждую программу. И здесь двояко: с одной стороны изменения очевидные, и достаточно пройтись по коду автоматическим инструментом чтобы всё поменять, с другой стороны я такое буду делать только на живых проектах, это всё равно работа.
Плюс библиотеки в Composer. При обновлении с PHP 7.4 на PHP 8 например минимум 90% из них будут работать без изменений. А при предложенном автором изменении сломается каждая вторая из них, если не каждая первая. И сколько времени потребуется на их обновление?
или
По поводу выпиливания текущей реализации стандартной библиотеки сложно, так как она используется очень часто. Процент кода, на который это повлияет будет сильно больше, чем у предыдущих ломающих изменений PHP. Функции будет довольно просто заменить чем-нибудь типа Rector, но руками это будет нереально.
Т.е. даже если персонально вам VPN поможет, то друзей и знакомых в замедленной или заблоченной социальной сети всё равно будет становиться всё меньше и меньше.
как?
Но из-за обязательной обратной совместимости (в том числе по отношению даже к странным и глючным решениям) нельзя просто отрефакторить какой-то метод API. Однажды сделанное неоптимальное решение остаётся в вебе навсегда. Неудобно? Делаем новый стандарт. Вёрстка на таблицах не катит? Верстаем на дивах. Неудобно? Flexbox. Всё равно неудобно? Grid. Какие-то api забрасываются, разрабатываются новые с похожим функционалом. И весь этот легаси надо поддерживать.