Именно. И, продолжая мысль, можно смело утверждать, что ни Хабра, ни Гитхаб, ни SO не свергнут LinkedIn и ему подобных просто потому, что популярность — дело относительное.
Ммм… Почему нанять? Речь как я понял о том, что кто-то хочет нанять человека, которого я знаю и спрашивает у меня по поводу него.
Лично мой аргумент тут такой, что у меня с человеком могут быть разные отношения (они, кстати, тоже показатель профессионализма), и я могу желать ему разного. Не вижу причин откидывать своё отношение, т.к. спросили меня, а взаимоотношения, как я уже сказал, это часть работы.
Я как раз про Россию спросил (извиняюсь, что в первом комментарии не указал).
Т.е. любые ресурсы, которые кто-то считает убер-полезными для тех или иных целей, на деле оказываются практически бесполезными для тех же целей в определённых группах населения (страны, города, континенты, т.п.).
Я вот сколько читаю про LinkedIn, всё не могу поверить — его реально используют?
У меня года 3 висела резюмешка там, даже обновляемая. Ни одного запроса. То же самое запихнул на HH — на следующий же день повалились звонки/письма.
В виду этого, от LinkedIn пароль каждый раз восстанавливаю, т.к. забываю, какой установил ранее. Захожу, поброжу по унылому, на мой взгляд, интерфейсу и закрываю.
Может быть странно, но я ищу ответы в сети, а не именно на SO. И моя статистика увы такая, что вне SO я получаю нужных ответов больше.
Видимо, я что-то делаю не так…
Работаю с 4й версией.
Стили из «источника» убиваются по собственному желанию редактора. Настроить стили для таблицы так, чтобы редактор их не трогал, после 3х часов так и не получилось. Самовольный варпинг тегами, который просто нельзя отменить (по словам самих разработчиков) также добавляет веселья.
Меня и как разработчика, и как редактора статей уничтожает работа с этим инструментом. Ну и в добавок разработчики на запросы отвечают долго (от недели).
Ну а какой редактор на ваш взгляд лучше?
Увы, приходится либо велосипедить, либо титанически менять поведение или ckeditor или tinymce. По глючности они примерно равны.
Система управления конфигурированием — перенос конфигов в файлы
Чисто субъективно, конфиги в json/yaml более наглядны, чем в БД (не беру монго). Кроме этого, с точки зрения стабильности, упавший сервер с БД — и всё, ваша система не «соберётся». В случае файлов, упавший сервер БД меньше влияет на работу системы. Кроме того, настройки подключения к БД не представляю как хранить в БД, а это ж тоже конфигурация.
Подводя итог, да, вы правы, вопрос действительно спорный (помнится мне, была на хабре статья про сравнение производительности системы в зависимости от способа хранения конфигов, если кратко — БД там проигрывала) и не революционный.
Напишу о наболевшем. Это ckeditor. По стечению обстоятельств приходиться им пользоваться — это ад. Всплывает столько багов и непредсказуемого поведения, что дрожь берёт, когда понимаю, что скоро придётся в нём что-то набирать.
Знаете, вспоминается Черчилль: «Если убить убийцу, количество убийц не изменится». Здесь аналогично: если «жульничеством» победить жулика, то количества жуликов не изменится.
Предлагаю вам посмотреть на ситуацию с другой стороны.
Есть заказчик, ему нужна прибыль, он хочет продать товар. Чтобы больше получить, теряя меньше, он нанимает быдлокодеров новичков, которые и архитектуру варганят, и всё остальное.
Итог: товар через день эксплуатации сдох продан, быдлокодеры новички получили свои печеньки и отпрвились на другой шлако-генератор проект говнокодить набираться опыта.
Что я пытался объяснить: если новичок не хочет становиться профи, он всегда будет новичком. Т.е. это не односторонний процесс: не только «тимлид» должен думать, на что лучше направить новичка, но и новичок должен думать, чего он хочет от своей работы: печенки с изюмом, печенки без изюма, изюм без печенек, опыт или мастерство.
Сорри за не совсем по теме комментарий, но вы, видимо, оочень давно на РНР писали. За последние лет 5 не припомню проблем с отладкой кода на этом языке.
p.s.
Глядя на схемки в статье и вспоминая принцип бритвы Оккама, можно сказать, что возможно решение добавить слой nodejs — не совсем верное.
В принципе понимаю причину вопроса, но, к сожалению, за все собеседования, что провёл, слышал всегда примерно одинаковое (причём у совершенно разных по опыту, заинтересованности и профессионализму людей). Поэтому к этому вопросу теперь отношусь скептично.
Если по-занудствовать, то не всё боевое участвует в войне — многое для случая войны. Т.е. если будет война — будет использоваться, если не будет, то не будет.
А если более по делу:
production server — скучно
боевой сервак — веселее (:
А на мой взгляд, в термине «боевой» есть несколько приятных моментов:
1. Продажа ПО (да и вообще продажи) во многом похожа на войну, ведь конкурентов никто не отменял. И тут у нас есть кмб (тестовый сервер) и боевая обстановка, где всё может меняться достаточно быстро и нужно реактивно принимать решения.
2. Этот пункт, лично мне, даже более дОрог: просто весёлое скрашивание и без того скучного мира терминов, преобладающее число которых навязывается из-за бугра. Я люблю игры, очень. И мне приятнее работать, принимая всё как игру (не в буквальном смысле) — просто веселее и охотнее работать. Т.е. на самом-то деле совершенно всё-равно как вы назовёте розу (по мотивам Шекспира) — в данном случае, главное, чтобы было понятно команде и приятно использовать принятое название.
Лично мой аргумент тут такой, что у меня с человеком могут быть разные отношения (они, кстати, тоже показатель профессионализма), и я могу желать ему разного. Не вижу причин откидывать своё отношение, т.к. спросили меня, а взаимоотношения, как я уже сказал, это часть работы.
Т.е. любые ресурсы, которые кто-то считает убер-полезными для тех или иных целей, на деле оказываются практически бесполезными для тех же целей в определённых группах населения (страны, города, континенты, т.п.).
Хм. Если б у меня спрашивали подобное, то я бы отвечал скорее то, что считаю нужным, а не то, что есть на самом деле. Сомнительный плюс.
У меня года 3 висела резюмешка там, даже обновляемая. Ни одного запроса. То же самое запихнул на HH — на следующий же день повалились звонки/письма.
В виду этого, от LinkedIn пароль каждый раз восстанавливаю, т.к. забываю, какой установил ранее. Захожу, поброжу по унылому, на мой взгляд, интерфейсу и закрываю.
Видимо, я что-то делаю не так…
Стили из «источника» убиваются по собственному желанию редактора. Настроить стили для таблицы так, чтобы редактор их не трогал, после 3х часов так и не получилось. Самовольный варпинг тегами, который просто нельзя отменить (по словам самих разработчиков) также добавляет веселья.
Меня и как разработчика, и как редактора статей уничтожает работа с этим инструментом. Ну и в добавок разработчики на запросы отвечают долго (от недели).
Увы, приходится либо велосипедить, либо титанически менять поведение или ckeditor или tinymce. По глючности они примерно равны.
Чисто субъективно, конфиги в json/yaml более наглядны, чем в БД (не беру монго). Кроме этого, с точки зрения стабильности, упавший сервер с БД — и всё, ваша система не «соберётся». В случае файлов, упавший сервер БД меньше влияет на работу системы. Кроме того, настройки подключения к БД не представляю как хранить в БД, а это ж тоже конфигурация.
Подводя итог, да, вы правы, вопрос действительно спорный (помнится мне, была на хабре статья про сравнение производительности системы в зависимости от способа хранения конфигов, если кратко — БД там проигрывала) и не революционный.
А в остальном желаю удачи проекту.
Есть заказчик, ему нужна прибыль, он хочет продать товар. Чтобы больше получить, теряя меньше, он нанимает
быдлокодеровновичков, которые и архитектуру варганят, и всё остальное.Итог: товар
через день эксплуатации сдохпродан,быдлокодерыновички получили свои печеньки и отпрвились на другойшлако-генераторпроектговнокодитьнабираться опыта.Что я пытался объяснить: если новичок не хочет становиться профи, он всегда будет новичком. Т.е. это не односторонний процесс: не только «тимлид» должен думать, на что лучше направить новичка, но и новичок должен думать, чего он хочет от своей работы: печенки с изюмом, печенки без изюма, изюм без печенек, опыт или мастерство.
p.s.
Глядя на схемки в статье и вспоминая принцип бритвы Оккама, можно сказать, что возможно решение добавить слой nodejs — не совсем верное.
В принципе понимаю причину вопроса, но, к сожалению, за все собеседования, что провёл, слышал всегда примерно одинаковое (причём у совершенно разных по опыту, заинтересованности и профессионализму людей). Поэтому к этому вопросу теперь отношусь скептично.
А если более по делу:
production server — скучно
боевой сервак — веселее (:
Проще ко всему относиться надо.
1. Продажа ПО (да и вообще продажи) во многом похожа на войну, ведь конкурентов никто не отменял. И тут у нас есть кмб (тестовый сервер) и боевая обстановка, где всё может меняться достаточно быстро и нужно реактивно принимать решения.
2. Этот пункт, лично мне, даже более дОрог: просто весёлое скрашивание и без того скучного мира терминов, преобладающее число которых навязывается из-за бугра. Я люблю игры, очень. И мне приятнее работать, принимая всё как игру (не в буквальном смысле) — просто веселее и охотнее работать. Т.е. на самом-то деле совершенно всё-равно как вы назовёте розу (по мотивам Шекспира) — в данном случае, главное, чтобы было понятно команде и приятно использовать принятое название.
p.s. Каждый день война (Собаки Качалова)