Обновить
5
0
Михаил Деркач@skeevy

Frontend Developer

Отправить сообщение
Если бы проблемы кода решались неймингом…
Не знаю, зачем оно мне, но было интересно.
Хотя я думал, что в смарт засунуть реакт достаточно больно
Спасибо, было интересно почитать

Но как пользователь i18n-react не увидел никаких преимуществ для локализации в разрезе именно текста. Все манипуляции с кешированием берет на себя библиотека, есть гибкий HMTLBackendAPI, а для остального я использовал встроенный Intl
ни одна синтетика не даст реального результата, но если она претендует на высокий процент точности — уже хорошо
Да такой сценарий понятен, но, почему-то знание фреймворка Х превращает разраба в диснеевсого героя, у которого доллары в глазах крутятся
И затем компании тратят время на выбивание дури и подтягивание основ, но большинство не выдерживают и уходят работать на галеру, куда их с руками и ногами отрывают, попутно демпингуя в 0.

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

Достаточно холиварный вопрос, но на лицо:
1) типичная проблема образования — переполнение низкокачественными кадрами и шутка про «забудь, чему тебя учили» вообще не смешная становится, потому что это реальность.
2) чистый бизнес — получаем прибыль в моменте. Да, базу вроде бы дали, показали то и се, а как усвоили ученики уже не их проблема.
3) когда соискатель выходит на рынок, у него уже в теории ламборгини в гараже стоит через пару лет, а по факту у него глаза на лоб лезут, видя, что происходит за кулисами компаний. И Эльдорадо в виде программирования в целом оказывается даже не прикольно — оказывается, тут лутают бабки не за просто знание доки и что такое html и css, да и борода не признак хипстерства

Понять можно всех, но за одним вопросом стоит череда других и это явно не проблема библиотек. Скорее, их использования и то, спорно достаточно
Как писать код, который удобно анализировать
… не говоря, что ты «командный игрок», а рассказав мне, что анализ кода так же сложен для ревьюера, и что ты знаешь, как оптимизировать свои пул-реквесты, чтобы они были читаемыми и понятными.


Читая вот это какой-нибудь джун запомнит это и будут писать mySuperNewAwesomeFunctionThatMakesSomeCoolStuff и будет ставить читабельность кода превыше его эффективности. Тут вопрос о компромиссе чтения кода и его работы. И вопрос, можно ли написать такой код, который будет эффективен, при этом ревьювер потратит 3 минуты на чтение его и сразу поймет?

Как разобраться в любом JS-фреймворке
… потому что дело не в звёздах GitHub, а в общих принципах, разделяемых большинством современных JS-фреймворков. Определение сильных и слабых сторон других фреймворков позволяет лучше понимать выбранный тобой фреймворк.


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

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


«почему?» не объясняет «как?». Вот та самая библиотека Х как правило на первой странице своей документации отвечает на некоторые «почему?» и «как?».

у каждого проекта есть технический долг, нужно перестать ныть об этом и приступать к рефакторингу. Каждой новой фиче должен предшествовать небольшой рефакторинг кода.


Рефактор ради рефактора — хождение по кругу. Это не дает, конечно, право писать плохой код и все выходящие, в т.ч. опыт написания кода, но как правило техдолг остается техдолгом навсегда, потому что бизнесу вообще плевать на эффективность твоих алгоритмов до тех пор, пока он из-за этого не теряет деньги. Конечно, можно программировать «для души», но лично такой подход в моей жизни еще не прокормил (это дабы пресечь сразу этот вариант), а задачам бизнеса, снова, плевать на твою душу.

Я к чему вообще веду. Может, не реакт испортил разработку, а сами разработчики? Гикбрейнсы, Хекслеты, Яндекс.Практикумы, выпускающие непонятного кого, которые, наслушавшись обещаний о классной работе и печеньках в офисах, на собесе требуют 100к+ зарплаты?
Вам бы в депутаты, уже даже есть слоган — «5 раз подумай, а то не одобрят!»
как же так, ведь в 7 был такой классный Пуск, ух, а вот эти плитки все фу-фу-фу!
В комментариях уже была шутка про что-то в духе «Новый Пуск — Панос?»
Сейчас есть проект на работе, где нужны реализовать микрофронты + хост. Есть CI/CD и все тому прочее, проект крупный. Но «женить» это все очень больно, особенно, когда оказалось, что нельзя бить на чанки js дочерние модули (это из особо критичный проблем).
Кое-как франкенштейн работает, но сердце щимит от того, что есть Module Federation, который по сути решает кучу проблем, но…

Пробовал по-разному, полный шаринг всех пакетов в хосте и микрофронтах по Advanced API из примеров в репозитории, но «не повезло, не фортануло» (с). Кое-как адаптировал текущие решения из Module Federation к своему проекту и работать даже начало стабильнее, монтирование/размонтирование, по крайней мере, работает как часы

Заинтересовал config в ваше примере, о нем нет никакой информации. Может именно там есть что-то, что поможет мне :) Да и было бы интересно посмотреть на вашу демку

За статью спасибо конечно, хотя у меня навернулись слезы, потому что я не смог в Module Federation :(

Аккордеон генератор на радио инпутах…
Где-то плачет <details /> и адепты семнатики и доступности.


Да и в целом с новыми девтулзами в хроме и гриды можно набросать быстро

Пуск же можно растянуть за края где-то аж на три четверти экрана. Неужели так не все часто нужные иконки помещаются в видимой части? Также их можно ж сделать мельче, в четверть от обычного размера (правда, подписи тогда не будет).


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

В общем, я не понимаю людей, которые на рабочем столе ярлыки хранят. Это отголоски каких-то древних привычек


Если это адресовано лично мне, то я нигде и не говорил, что храню и тем более пользуюсь ярлыками с рабочего стола. Установилась софтина, создала ярлык — и фиг с ней. Свой юзкейс я описал выше

А так — так все мы и живем привычками. Чистить зубы тоже привычка, по сути. Ярлык потерять не страшно, а документ важный — да, и я не понимаю тех, кто конкретно документы рабочие и важные на РС хранят. Не понимаю, но и не осуждаю.
То же самое, только не храню ничего в облаках (семейные фото, аудиотека и т.д. на внешнем винте), остальное в репозиториях.
На рабочем компе только ярлыки Outlook, интранета, телеги, зума и рабочий софт (и то, рабочий софт закреплен в панели)
Только кейс описанный в статье касается рядового офисного сотрудника, который часто работает с документами и обычно хранит их на постоянной основе на рабочем столе.

Лично у меня всегда пригорало, когда я видел компьютер матери и у нее весь рабочий стол в таблицах экселя, хаотичен и при этом она разбирается во всем этом :D
Справедливо, но не всегда удобно прокручивать пуск, особенно если что-то в папках и т.д. В общем, новый пуск я не использую на полную катушку :)

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

Как временное хранилище — вполне себе и, видимо, так это и подразумевалось в принципе, однако, юзверь зверь непредсказуемый :D
никогда не храню важные файлы на рабочем столе, с учетом нескольких смертей hdd без возможности восстановления.
рабочий стол должен быть хранилищем ярлыков быстрого доступа или группированного контента в моем понимании.

А если РС является файлопомойкой, то боюсь представить, что будет, если в 10ке использовать виртуальные рабочие столы и захламлять каждый
Прочел статью и не понял. Точнее, понимание уже есть, но мне объяснение давали такое:
элемент — фактически присутствует, узел — в целом абстрактная единица, его можно создать js, но не вставить на страницу. И в зависимости от методов, мы создаем либо узлы, либо элементы (appendChild vs InsertAdjacentTML)
Смотрю, что у многих возникает вопрос уровня Android vs iOs, Windows vs Linux.
Скажу одно — пока вы не попробуете и то, и то на одной и той же задаче, то не поймете разницы. И задача должна быть не уровня «сверстать лендинг» или набросать страницы в паге и собрать воедино.

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

Пока вы смотрите и на гальп и на вебпак в разрезе конкатенации файлов и перекладывании файлов из src, в dist, то однозначно вам подойдет gulp и вебпак излишен:)

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Фронтенд разработчик
Ведущий
От 450 000 ₽
JavaScript
React
TypeScript
Webpack
MobX