Pull to refresh
64
Karma
0
Rating

Раздоры вокруг <div>

Accessibility в вебе — это не сложно на самом деле. И семантические интерактивные элементы — важная его часть. Иначе получится postman. Который из-за отсутствия семантики почти не юзабелен. А вот тег footer, действительно, не принципиален.

Не нужно стыдиться PHP

Даже по вашей ссылке php занимает вполне хорошее место. А с учетом того, что он, в отличие от прочих ЯП, представлен только в одной области, так вообще отличное.


Наследие эпохи PHP ещё долго будут разгребать и какие-то улучшения там происходить ещё точно будут.

Новые проекты на нем все так же пишутся. В своей области он вполне популярен.


Нужны какие-то очень весткие мотивы, чтобы заманить их обратно.

Я считаю, что у php довольно пологая кривая обучения, плюс Очень хорошая инфраструктура в своей области. Часто слышу, что php разрабов проще найти / они меньше стоят, что немаловажно для компаний.
Так что доля php может глобально и снижается, особенно за счет узости его применения. Но жизнь на нем вполне есть. И профессионал, и новичок в ближайшие 10 лет без работы не останутся.

Не нужно стыдиться PHP

На рынке кроме фактора спроса на язык есть еще и предложение спецов, умеющих в него. И на php, imho, проще начинать. В т.ч. из-за кучи фриланса и простых инструментов на нем.


переучись ты на другой стек, это не так уж сложно, если голова работает правильно…

А чем backend на java принципиально лучше, чем на php?
У меня в команде работал чел, перешедший с C# на php. Говорил, что Doctrine получше чем EF. Да и работу новичку проще найти.


И будут за тобой стоять очереди эйчаров.

За толковыми php-шниками тоже очередь. Видимо, везде сейчас так.

Не нужно стыдиться PHP

На php куча админок, систем управления делается. В т.ч. и с нуля. Как-то в разработке онлайн банка участвовал. На почту постоянно идет поток предложений рассмотреть ту или иную вакансию. Так что с редкостью COBOL вы уж совсем мимо.


И сам php как язык, отягощенный обратной совместимостью с не самыми лучшими решениями, по сравнению с новыми ЯП может и не очень. Хотя и он неплохо развивается. Но вот удобных фреймворков и библиотек на нем написана масса. Так что в целом разрабатывать легко и приятно.

Сегодняшний UI хабра

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

Парадокс Ферми – вовсе не парадокс, а вопрос; в чём он состоит, и как его решать (часть 1)

Мне кажется в вопросе заселения цивилизацией местной галактики есть несколько спорных предположений:


  1. Цивилизация стремится к неограниченной экспансии.
    Во всех развитых странах уровень рождаемости последнее время снижается. Вплоть до отсутствия воспроизводства населения. Легко предположить, что в относительно скором времени все население земли перестанет расти. А в таком случае для чего нужна экспансия? Ресурсов земли должно хватить на всех. А сидеть в своем смартфоне куда проще и интереснее, чем бороздить бесконечные просторы.


  2. Технологии развиваются неограниченно.
    Последние столетия наука развивалась очень быстро и сильно поменяла нашу жизнь. И успевшим к этому привыкнуть кажется, что так будет продолжаться всегда. Но в плане физики все скорее наоборот. Значимые с точки зрения практического использования явления открывать все сложнее и сложнее. Да и космические технологии развиваются куда медленнее, чем ожидали фантасты середины 20 века. Что уж говорить о приближении скорости перемещения в пространстве хотя бы к скорости света, без чего сложно представить межзвездные перелеты.



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

Когда очень хотелось получить работу в Америке или в бою все средства хороши

С каждым следующим поиском работы все прохладнее отношусь к тестовым заданиям.


  1. В большинстве мест меня прекрасно брали и без них, после чего мы долго и успешно сотрудничали.
  2. Задание часто требует больше времени, чем ты ожидаешь. Все-таки не каждый день нужно заново настраивать проект со всеми зависимостями. Плюс мне как бекендеру дают интеграцию с какими-нибудь апи внешних сервисов. Т.е. ты параллельно должен еще разобраться и с ними.
  3. Жестко выбешивает, когда запрещают пользоваться фреймворками. Алло, у меня даже в резюме в графе должность / роль стоит "%framework_name% developer". И откликаюсь я именно на те вакансии, где он и используется. Но нет, ребятам хочется проверить "мои общие подходы". После чего ты каждый раз изобретаешь тот же фреймворк заново. Привет пункту 2.
  4. Твою работу часто оценивают по принципу нравится / не нравится. У разрабов "я бы сделал иначе" и "ты написал фигню" нередко означает одно и то же. А попробуй по общим формулировкам ТЗ понять, что они хотят увидеть, да еще и в велосипедном исполнении.
  5. Ну, и в конце они на тебя еще и забивают. Я чуть ни 2 недели бегал за одним товарищем, чтоб получить хоть какую-то обратную связь по тестовому. Ок, я уже понял, что вы меня не берете. Но оцените хотя бы то, на что я потратил все свое свободное время за 2 дня. В итоге он мне еще и по ошибке прислал отзыв по другому кандидату…
    Туда же можно отнести и задание тестового, когда решение по твоей кандидатуре уже есть / от него не зависит. В этом легко могу понять негодование автора исходной статьи. Когда ты кучу времени делаешь никому не нужную ерунду, а в итоге тебе отказывают по совершенно другим причинам — это вызывает яркие эмоции.

Детройт: как мировая моторная столица дошла до банкротства

повышают покупательную способность широких слоев населения — что, в конечном счёте, повышает прибыль собственников.

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

ADOBE Systems — история удивительного успеха

Было интересно, спасибо.


В подобных статьях однако любят выпячивать роль конкретной личности, задвигая на задний план ту среду, в которой они жили.
То же решение уйти вникуда из большой стабильной компании не выглядит столь безрассудно, если принять во внимание, что они находились в самом центре быстроразвивающейся отрасли. Где вокруг, как грибы после дождя, возникали успешные стартапы. А за углом жил знакомый венчурный капиталист, готовый вложить пару миллионов долларов в технологии, над которыми они до этого работали несколько лет.

Новые АЭС в России и рост доли атома до 25%

Имхо подогнать парочку малых плавучих АЭС выглядит как-то реальнее. С дивана, как минимум.

Новые АЭС в России и рост доли атома до 25%

Есть. Поэтому там решили не строить АЭС, а подогнать плавучие реакторы и переработать энергосистему под них. Плюс там планируются крупные проекты по добыче полезных ископаемых. Так что электричество очень нужно, и окупаемость должна быть достигнута.

Как вырастить тупого ребёнка (научно обоснованные вредные советы)

если верить статистикам, превосходил танки/самолеты/артилерия Германию

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


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


вообще без подготовки бросать людей, это я и называю "забросать мясом".

Можно сейчас выдвигать любые благие пожелания на этот счет. Но ни ядерного оружия, ни спутниковой разведки, ни реактивной авиации у РККА на тот момент не было. И принципиально лучшую подготовку форсирования Днепра в тех условиях обеспечить было нельзя. И можно, конечно, говорить, что в той ситуации "врага забросали мясом". А можно, напротив, сказать, что быстрым форсированием спасли ни одну сотню тысяч жизней. Т.к. пробить устоявшуюся оборону по реке — это совсем другие потери. Да и параллельный геноцид находившегося под оккупацией населения никто не отменял.


именно такие действия и называются "забросать мясом"

Можете называть, как вам угодно. Но по мне детальный анализ того, что случилось, зачем и почему, более продуктивен, чем громкие эпитеты.


Ну, и если даже смотреть на итоговое соотношение потерь за всю войну, то оно вполне сопоставимо с поправкой на катастрофическое ее начало и организационно-технологическое превосходство Германии. Так что методы ведения войны в тех условиях примерно схожи и потери — тоже.

Как вырастить тупого ребёнка (научно обоснованные вредные советы)

Что по официальным данным СССР?


В любом случае не вполне понял вашу мысль. Локальное описание может быть вообще любое. А Днепр был форсирован относительно быстро и успешно. Сравните, например, с целом годом боев под Ржевом.


Немцам тогда еще менее сладко приходилось. Быстро отступать, часто в беспорядке — это совсем не весело. А на западном берегу их еще и несколько котлов ждало.

Современное пиратство глазами моряка. Наёмники

даже в мыслях не имеют научиться чему-нибудь полезному

А что полезнее в тех условиях может быть умения хорошо пользоваться АК?


проклятые каписталисты их ограбили!

Вы так говорите, как будто Атлантического треугольника а потом и колонизации не было. Или вы думаете, что столетия разрушения итак слабых местных государственных институтов никак не влияет?

Функциональный Kotlin. Часть 2. Каррированные функции и где они обитают

Как раз изучаю Haskell. Там каррирование используется в основном, чтобы частично примененную функцию потом передать в функцию высших порядков. Ну, и для того, чтобы в бесточечном стиле лишние аргументы не пробрасывать. Еще прикольно одну функцию частично применять к другой. Результирующий тип по началу кажется очень неожиданным.

Java: есть ли жизнь на десктопе?

Так же нужно следить за хостингами, доступностями, SSL сертификатами и пр.

Github pages очень удобен в этом плане.


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

В вебе релиз полностью под твоим контролем. Мне наоборот казалось, что это преимущество. Нашел багу — обновил сразу для всех. Нужно откатиться — для stateless сервиса это очень легко делается.


Но вообще ваше решение хорошо понятно и имеет безусловные плюсы. Особенно в контексте работы по флешке.

Статический анализ и уже выросший проект: внедрять нельзя откладывать

Может и можно через дженерики возвращать сущность из entityManager с не nullable id. Но при инжекте в контроллер с помощью ArgumentResolver уже придется прописывать дженерик вручную. Да и потом везде его по типам пропихивать. Так что трейт с getInitializedId с ассертом внутри кажется меньшей проблемой.


А ведь кроме id у сущности может быть куча автозаполняемых полей. CreatedAt updatedAt, createdBy… Часто они в doctrine event subscriber автоматом заполняются. Но тогда их тоже нужно делать nullable.


Я на одном небольшом проекте для себя успешно подружил Psalm с сущностями доктрины.

На моем текущем проекте у сущности может быть несколько десятков полей. Ну, пусть даже 10 из них не nullable. Как-то сомнительно их все через конструктор инициализировать. Да и формы с таким по дефолту не очень дружат. Не знаю насчет апи платформы и прочих библиотек..

Как вырастить тупого ребёнка (научно обоснованные вредные советы)

(вермахт передвигался буквально на лошадях

Пехотные дивизии — да. Элитные танковые части, составляющие около 10% были полностью моторизованы. И именно они составляли основной элемент блицкрига. Т.к. танковая армия — это 150 — 200 тысяч человек, с танками, бронетранспортерами, моторизованной артиллерией, способных проходить по 100 км. в сутки. Именно они резали советскую оборону вначале войны. Пехота занимала территорию и добивала окруженные части.

Как вырастить тупого ребёнка (научно обоснованные вредные советы)

Слышал, что отношение потерь РККА за ВОВ к потерям немцев и их союзников оценивается в 1,5 — 2 раза. Причем за 1941 соотношение было чуть ли не 4 / 1. Это было вызвано в основном большим количеством котлов, в которые попадали РККА в начале войны. Где гибли / попадали в плен целые армии и фронты со всем тыловым обеспечением. Во второй половине войны ситуация во многом отзеркалилась. Но соотношение до конца не выправилось.


А по поводу методов войны… Воевать можно тем способом, который позволяет обстановка и наличные ресурсы. Нельзя в середине войны объявить паузу, чтоб нарастить количество поддерживающей действия пехоты артиллерии. И обученный, вооруженный и организованный личный состав для генерала — это такой же ресурс. Не нужно думать, что он бесконечен / не имеет ценности.


Ну, и насчет форсирования Днепра… Форсировать препятствия проще всего сходу. Фронт к тому моменту быстро катился на запад. Если дать ему остановиться. Противник закрепится на западном берегу и сбивать его оттуда будет очень тяжело. А так все произошло быстро и с небольшими потерями в контексте сложности задачи.


Так что у войны мрачная логика. Но она все-таки есть.

Статический анализ и уже выросший проект: внедрять нельзя откладывать

Сам подключал psalm на прошлом проекте. Было интересно попробовать. Но в итоге впечатление сложилось двоякое. С одной стороны круто иметь статическую типизацию на php. С другой сама экосистема к этому была не слишком приспособлена. Те же symfony / doctrine тогда не имели нужных аннотаций. Да и вообще куча кода была написана с ориентацией на динамическую природу php.


Я причем эмпирически выставил строгость проверки что-то около 3. И в основном приходилось бороться с "вопросиками". Т.е. избавляться от nullable. И я до сих пор не до конца понимаю, как это нужно правильно делать, например, для сущностей доктрины. Т.е. все не nullable свойства с точки зрения типов нужно инициализировать в конструкторе. Но это сильно выбивается из общей практики. То же самое с автоинкрементным id. При создании новой сущности он должен быть null. Но потом этот вопросик сильно мешается в коде. Приходится добавлять во все сущности getInitializedId() :int с ассертом внутри. И так много в чем. Когда с точки зрения контекста использования ты знаешь лучше анализатора, что за реальный тип у этого значения.

Information

Rating
Does not participate
Registered
Activity