Даже в экстремальных случаях, когда мы сравниваем самого бедного сеньора с самым богатым лидом разброс будет меньше. В среднем по больнице разброс будет процентов 20-30.
Я собеседовал немало людей, который отлично мне на high-level рассказали, как они красиво бы запроектировали и слова говорили правильные, а когда начинали писать код, то там была жуткая императивщина, забытые пограничные условия и весьма трудночитаемый код — 15-20 строк хватает, чтобы понять, что человек писать умеет плохо.
Да, в начале проекта будут бездумно копи-паститься решение со StackOveflow и будет казаться, что все хорошо, но потом полезут баги, а поддержка проекта будет очень сложной и дорогой.
Все это не противоречит тому, что многие интервью проводить не умеют. В whiteboard не вижу ничего плохого, и если кандидат не может вспомнить название функции — это вообще не проблема. А вот если у него код на 5 строк и там есть ошибка с выходом за пределы массива и он сам ее не находит даже после подсказки, то упс.
Можно дом простроить без молотка, но зачем? Синглтон — это точно такой же инструмент проектирование, как и другие. Если его использовать неправильно — будет нехорошо. Ну так это как молотком по пальцу заехать в первый раз и после этого обвинить инструмент в том, что это он такой плохой и лучше его никогда не использовать.
Аргумент про SOLID не особо уместен, как уже написали выше. Про разные источники данных — в моделе я вообще не хочу знать, откуда у меня берутся данные, persistence разруливается на более низком уровне, поэтому это неудачный аргумент, если предположить, что у проекта нормальная архитектура. С тестированием проблема выглядит сильно надуманной, по крайней мере у нас нет проблем с тестированием синглтонов. Может быть это потому, что мы их проектируем соответствующе.
То есть получается, что в самом синглтоне ничего плохого нет, но если этот паттерн использовать неверно, то можно усложнить себе жизнь, но ведь это справедливо для всего чего угодно. Заменить сингтон фабрикой в общем случае звучит как шизофрения.
Не хочется вешать ярлыки, но разработчик WordPress этой статьей лишний раз подтвердил, что там все очень плохо :/
Блин, возмущен он. Я наверное последний раз отвечаю, так как в статьях все это описано, только подробнее.
Во время SSR сервер рекурсивно обходит компоненты (для этого надо какую-нибудь либу взять или самому этот механизм реализовать) и собирает какие запросы к API нужно выполнить, чтобы отдать страницу со всеми данными.
После того, как список запросов известен, сервер их выполняет, их результат сохраняется в redux store и только после этого выполняется рендеринг с использованием всех нужных данных из стора. В результате получается HTML страница со всеми данными. Это страница + состояние redux store отдается клиенту.
Клиент отображает HTML и в фоне загружает JS, инициализирует Реакт приложение и загружает в redux начальное состояние, которое передал сервер.
Соответственно, SE и другие, лишенные JS, просто получают HTML с данными и до JS шага не доходят, что в принципе ок.
SSR делает такой же запрос к API как и приложение в браузере. Если ты один раз сделаешь честное профилирование, то увидишь, что разница между http и прямым запросом к БД будет не очень большой, но взамен:
1) ты не привязываешься к БД: сервис предоставляет интерфейс, а откуда он берет данные неважно (сейчас БД, потом nosql, потом что-нибудь еще)
2) ты не пишешь два раза код, который делает одно и тоже (SSR дергает бд, frontend — API)
3) frontend никогда не должен лезть в БД напрямую в боевом проекте. У тебя просто заберут весь контент и все
timeRequest() тут исключительно для Proof of Concept, в статье описано, что в реальной жизни так лучше не делать.
Мы же не можем каждый URI обрабатывать в файле server.js.
React Router. В моем бойлерплейте используется очень старая 2я версия, актуальная 4я гораздо лучше решает эту задачу, и также поддерживает динамический роутинг
webpack — это сборщик, он конвертирует проект в конечные ассеты: js и css
webpack-dev-server — это сервер, который запускает webpack для первоначальной сборки и далее для каждого измененного файла. Его задача: сборка + хостинг ассетов в процессе разработок + hot reload, то есть обновление страницы в браузере автоматически в процессе разработки
С чего взято, что время сборки занимает 30 секунд?
Да, так и есть, номинации только выдают не по особенностям реализации, а по бизнес составляющей, например, "лучшее дополнение SmartCity", "развитие местных и региональных сообществ" и так далее. Баги и красивый код никому не интересны.
Этот конкурс куда ближе к фигурному катанию, где много субъективности, чем к бегу на 100 метров, где все делают одно и тоже, и надо понять, кто делает это лучше. От такого конкурса куда больше пользы: https://habrahabr.ru/post/329500/#comment_10236650
Дома имеет смысл придумать идею и подумать, что нужно для ее реализации — не больше.
1) На хакатоне мы не можем исходить из предположения, что "город, государство или компании купят у нас наш продукт", поэтому мы работаем с конечным потребителем. Мы можем обосновать два места, можем сделать модель на 3 и 4 (если вся семья на колесах), но вот больше — вряд ли
2) Можно прийти на хакатон со всем готовым, но, организаторы, жюри, журналисты и спонсоры ходят в процессе творения, смотрят, общаются, помогают, задают вопросы, — сложно будет их всех обмануть. Ну, и люди примерно представляют, что можно сделать за сутки, а что — домашняя работа. Да, и если честно, я смогу найти, как более выгодно время потратить :)
3) В статье есть ссылка на гитхаб, где лежит исходный код приложения, оно под iOS.
Любой замок можно взломать. Мы думали об этом и пришли к выводу, что если продавать замок чуть дороже и заложить стоимость страховки, а также интегрироваться с городскими камерами, то это решило бы проблему. Это хоть и важные моменты, но вторичные, поэтому они не вошли, ни в речь, ни в демо.
Во-первых, это интересно — есть возможность посмотреть, что делают другие, пообщаться и познакомиться, лучше понять, куда движется мир технологий и что будет сильнее востребовано в следующие пару лет.
Во-вторых, выигранный хакатон — это очень сильный маркер как для работодателя, так и для инвестора, что перед ними человек, который вероятно обладает набором ценных качеств: целеустремленный, способный придумать и воплотить в жизнь и продать стоющую идею за ограниченный промежуток времени в стрессовой ситуации, умеющий работать в команде. Это выигрышная история для обеих сторон: исполнителям проще доказывать свою состоятельность, заказчикам — делать хороший выбор.
В-третьих, по статистике после хакатона лишь 2% проектов воплощается в жизнь, но это лишь вершина айзберга — этот опыт поможет кому-то начать свой собственный небольшой проект или сделать полноценный стартап. Также отличный способ посмотреть друг на друга в стрессовой ситуации и понять, имеет ли смысл делать совместно что-то более серьезное.
В-четвертых, это отличная история для спонсоров и индустрии в целом: у Cloudflare до дизрапта было меньше 100 клиентов, после — 5000. Неплохо для одного дня, не так ли?
Даже в экстремальных случаях, когда мы сравниваем самого бедного сеньора с самым богатым лидом разброс будет меньше. В среднем по больнице разброс будет процентов 20-30.
ЛАНИТ ЛАНИТ ЛАНИТ театр ЛАНИТ ЛАНИТ технологии ЛАНИТ дочка ЛАНИТА ЛАНИТ-интеграция
А разве кто-то заставляет туда идти работать?
<сарказм>Теперь будет что на собеседованиях спрашивать!</сарказм>
Я собеседовал немало людей, который отлично мне на high-level рассказали, как они красиво бы запроектировали и слова говорили правильные, а когда начинали писать код, то там была жуткая императивщина, забытые пограничные условия и весьма трудночитаемый код — 15-20 строк хватает, чтобы понять, что человек писать умеет плохо.
Да, в начале проекта будут бездумно копи-паститься решение со StackOveflow и будет казаться, что все хорошо, но потом полезут баги, а поддержка проекта будет очень сложной и дорогой.
Все это не противоречит тому, что многие интервью проводить не умеют. В whiteboard не вижу ничего плохого, и если кандидат не может вспомнить название функции — это вообще не проблема. А вот если у него код на 5 строк и там есть ошибка с выходом за пределы массива и он сам ее не находит даже после подсказки, то упс.
А что с производительностью не так? Быстрее только C/C++ будет при условии, что написан правильно
Это очень плохая статья.
Можно дом простроить без молотка, но зачем? Синглтон — это точно такой же инструмент проектирование, как и другие. Если его использовать неправильно — будет нехорошо. Ну так это как молотком по пальцу заехать в первый раз и после этого обвинить инструмент в том, что это он такой плохой и лучше его никогда не использовать.
Аргумент про SOLID не особо уместен, как уже написали выше. Про разные источники данных — в моделе я вообще не хочу знать, откуда у меня берутся данные, persistence разруливается на более низком уровне, поэтому это неудачный аргумент, если предположить, что у проекта нормальная архитектура. С тестированием проблема выглядит сильно надуманной, по крайней мере у нас нет проблем с тестированием синглтонов. Может быть это потому, что мы их проектируем соответствующе.
То есть получается, что в самом синглтоне ничего плохого нет, но если этот паттерн использовать неверно, то можно усложнить себе жизнь, но ведь это справедливо для всего чего угодно. Заменить сингтон фабрикой в общем случае звучит как шизофрения.
Не хочется вешать ярлыки, но разработчик WordPress этой статьей лишний раз подтвердил, что там все очень плохо :/
Блин, возмущен он. Я наверное последний раз отвечаю, так как в статьях все это описано, только подробнее.
Во время SSR сервер рекурсивно обходит компоненты (для этого надо какую-нибудь либу взять или самому этот механизм реализовать) и собирает какие запросы к API нужно выполнить, чтобы отдать страницу со всеми данными.
После того, как список запросов известен, сервер их выполняет, их результат сохраняется в redux store и только после этого выполняется рендеринг с использованием всех нужных данных из стора. В результате получается HTML страница со всеми данными. Это страница + состояние redux store отдается клиенту.
Клиент отображает HTML и в фоне загружает JS, инициализирует Реакт приложение и загружает в redux начальное состояние, которое передал сервер.
Соответственно, SE и другие, лишенные JS, просто получают HTML с данными и до JS шага не доходят, что в принципе ок.
SSR делает такой же запрос к API как и приложение в браузере. Если ты один раз сделаешь честное профилирование, то увидишь, что разница между http и прямым запросом к БД будет не очень большой, но взамен:
1) ты не привязываешься к БД: сервис предоставляет интерфейс, а откуда он берет данные неважно (сейчас БД, потом nosql, потом что-нибудь еще)
2) ты не пишешь два раза код, который делает одно и тоже (SSR дергает бд, frontend — API)
3) frontend никогда не должен лезть в БД напрямую в боевом проекте. У тебя просто заберут весь контент и все
А потом фронтендик говнокодить :)
timeRequest() тут исключительно для Proof of Concept, в статье описано, что в реальной жизни так лучше не делать.
React Router. В моем бойлерплейте используется очень старая 2я версия, актуальная 4я гораздо лучше решает эту задачу, и также поддерживает динамический роутинг
webpack — это сборщик, он конвертирует проект в конечные ассеты: js и css
webpack-dev-server — это сервер, который запускает webpack для первоначальной сборки и далее для каждого измененного файла. Его задача: сборка + хостинг ассетов в процессе разработок + hot reload, то есть обновление страницы в браузере автоматически в процессе разработки
речь же не о хелло вордах
В статье описано, зачем нужен webpack-dev-server. Приведи конкретную цитату из статьи, которая тебе не понятна
Да, так и есть, номинации только выдают не по особенностям реализации, а по бизнес составляющей, например, "лучшее дополнение SmartCity", "развитие местных и региональных сообществ" и так далее. Баги и красивый код никому не интересны.
Этот конкурс куда ближе к фигурному катанию, где много субъективности, чем к бегу на 100 метров, где все делают одно и тоже, и надо понять, кто делает это лучше. От такого конкурса куда больше пользы: https://habrahabr.ru/post/329500/#comment_10236650
Дома имеет смысл придумать идею и подумать, что нужно для ее реализации — не больше.
1) На хакатоне мы не можем исходить из предположения, что "город, государство или компании купят у нас наш продукт", поэтому мы работаем с конечным потребителем. Мы можем обосновать два места, можем сделать модель на 3 и 4 (если вся семья на колесах), но вот больше — вряд ли
2) Можно прийти на хакатон со всем готовым, но, организаторы, жюри, журналисты и спонсоры ходят в процессе творения, смотрят, общаются, помогают, задают вопросы, — сложно будет их всех обмануть. Ну, и люди примерно представляют, что можно сделать за сутки, а что — домашняя работа. Да, и если честно, я смогу найти, как более выгодно время потратить :)
3) В статье есть ссылка на гитхаб, где лежит исходный код приложения, оно под iOS.
Выше написал: https://habrahabr.ru/post/329500/#comment_10236660
Спасибо за поздравления! Хакатоны и стартапы — это разные виды спорта :) Задачи, которые решает хакатон я описал выше: https://habrahabr.ru/post/329500/#comment_10236650
Любой замок можно взломать. Мы думали об этом и пришли к выводу, что если продавать замок чуть дороже и заложить стоимость страховки, а также интегрироваться с городскими камерами, то это решило бы проблему. Это хоть и важные моменты, но вторичные, поэтому они не вошли, ни в речь, ни в демо.
Во-первых, это интересно — есть возможность посмотреть, что делают другие, пообщаться и познакомиться, лучше понять, куда движется мир технологий и что будет сильнее востребовано в следующие пару лет.
Во-вторых, выигранный хакатон — это очень сильный маркер как для работодателя, так и для инвестора, что перед ними человек, который вероятно обладает набором ценных качеств: целеустремленный, способный придумать и воплотить в жизнь и продать стоющую идею за ограниченный промежуток времени в стрессовой ситуации, умеющий работать в команде. Это выигрышная история для обеих сторон: исполнителям проще доказывать свою состоятельность, заказчикам — делать хороший выбор.
В-третьих, по статистике после хакатона лишь 2% проектов воплощается в жизнь, но это лишь вершина айзберга — этот опыт поможет кому-то начать свой собственный небольшой проект или сделать полноценный стартап. Также отличный способ посмотреть друг на друга в стрессовой ситуации и понять, имеет ли смысл делать совместно что-то более серьезное.
В-четвертых, это отличная история для спонсоров и индустрии в целом: у Cloudflare до дизрапта было меньше 100 клиентов, после — 5000. Неплохо для одного дня, не так ли?
Интереснее выступить на чемпионате мира, чем на чемпионате России, если есть такая возможность