Может быть не очень корректно писать 2 комментария подряд, но, имхо, они разные, поэтому разделил.
Лично я считаю такой подход хорошим и даже стало интересно самому провести такой собес. Наверное, лучше всего предлагать кандидатам ситуации, которые реально случались на проекте, тогда решение кандидата можно будет сравнить с тем, как эта проблема уже когда-то решилась в реальности. И вот тут может оказаться несколько вариантов: 1. кандидат не додумается ни до какого решения, либо придумает что-то очень плохое вообще не туда; 2. кандидат будет мыслить в верном направлении и либо придет к тому же, - идеальный кандидат, либо ему чего-то не хватит, что тоже его делает отличным кандидатом, у которого еще всё впереди; 3. кандидат придумает решение еще круче.
В третьем варианте возможен даже сценарий, когда придется сказать кандидату: "круто, но наша команда не справилась бы с вашей идеей - вы слишком хороши для нас". Могу как совет предложить сделать чуть больше акцента в статье на том, что цель, наверное, даже любого собеса найти не лучшего, а наиболее подходящего.
Могу я попробовать: странный у него опыт, в котором он не встречался с тестовыми данными, которые разработчики частенько забывают убрать из публичной версии кода.
При десятипальцевом методе печати, если печатаем большую букву (или символ, для которого необходимо зажать шифт), которая находится в зоне ответственности левой руки, тогда зажимаем правый шифт правой рукой и наоборот, если буква в зоне правой руки, тогда зажимаем левый шифт левой рукой. Таким образом использование шифтов, грубо округлив, сводится к 50 на 50.
По поводу Scroll Lock лично я не вижу проблемы. Ребята, которые пользуются консолью и предпочитают без мыши, рано или поздно приходят к освоению vim (там можно скроллиться вверх/вниз также как описано в статье), после чего их жизнь меняется только в лучшую сторону, и Scroll Lock нервно курит в стороне. В продуктах JetBrains можно вернуться на предыдущее место (это пример, что в софте бывают и альтернативы не хуже Scroll Lock), а в остальном упомянутом софте как бы без мыши не обойтись в любом случае, а для достаточно редких случаев посмотреть, что там выше, не теряя текущей позиции, можно уже и до мыши дотянуться.
Но я наоборот старался подвести логическую цепочку к тому, что анализ не нужен - было бы интересно увидеть стату, но она ничего кроме удовлетворения интереса не даст сообществу, зато статья из разряда "Как написать полезную статью и не выгореть после прочтения комментариев к ней" потенциально могла бы решить (или поспособствовать ее решению) обозначенную проблему и была бы полезна сообществу.
По моему субъективному мнению комментарии на хабре весьма сбалансированы и частенько бывают полезнее самой статьи. Может я уже научился игнорировать левак, а может действительно на хабре не всё так плохо. Но советы авторам и всем остальным, кто мог бы "вступаться" за авторов статей и знать, когда корректно ставить минус комментарию, имхо, лишними не были бы.
Я так понял статья - это что-то вроде попытки обратить внимание сообщества на проблему. Может быть я плохо читал, но я не совсем до конца понял проблему, поэтому хотелось бы уточнить: речь о том, что бывают ситуации, когда неквалифицированные или недостаточно квалифицированные в вопросе люди оставляют комментарии, которые "отпугивают" авторов, так?
И предложение для решения этой проблемы - написать парсер? Допустим, у автора не хватает знаний или времени на написание парсера, но вот я и не вижу конкретного предложения по алгоритму. Сам же могу сказать, что я замечаю в IT сообществе проблему, что есть люди с очень неприятной комбинацией отсутствия достаточной квалификации в вопросе, но наличия уверенности в обратном, которые своим мнением могут "отпугивать" толковых спецов и было бы интересно пересчитать таких персонажей, но как это сделать очень хороший вопрос.
Подсчет мог бы дать общее представление о том, сколько таких, какая вероятность наткнуться, но уже сейчас без всяких анализов можно сказать, что их больше нуля и на пути каждого растущего спеца или автора наверняка такие попадутся не раз, так что следующей статьей в этом направлении могли бы быть советы, как действовать, когда перед тобой непонятно кто; какие уточняющие вопросы лучше задавать, какие бывают стоп-слова, при которых лучше прекращать общение с этим человеком и т. д.
Вместо того, чтобы предлагать сообществу не писать комментарии лучше предложить сообществу способ их отсеивания.
Как раз интересно посмотреть, как браузер отрендерит эти самые первые 14кб. Вот после прочтения статьи мне стало интересно подготовить заглушку в 14кб для пользователей с плохим интернетом. Как вариант стырить пакеты с wireshark, сохранить в файл, потом открыть в браузере... Но может уже есть готовые более простые варианты для отладки.
А какие есть способы отладки всего это счастья? Могу я как-то научить браузер после загрузки первых 14кб останавливаться, чтобы посмотреть, что получилось? И заодно узнать, отдает ли веб-сервер 14кб или больше в качестве первой пачки.
Даже очень =) Накатилась Bolt CMS без приключений, админка похожа, в доке вижу есть секция про ContentTypes, в которой практически все те же типы полей присутствуют, что в Grav. Но не увидел в документации и настройках ничего про формы (пользовательские), например, не нашел настроек smtp, чтобы отправлялись письма от CMS.
Очень интересная статья, при прочтении прям появлялось желание оказаться во всем этом процессе. Грамотно вставлены технические детали и корпоративные приколы. Буду ждать статью в таком же стиле о результатах тестирования. =)
Побочной фичей внедрения камеры контроля в машину может быть и контроль того, кто находится за рулем, как минимум чтобы это был хотя бы один и тот же человек для одной машины.
Тоже стало интересно, поэтому проверил, что же выдаст гугл на такой запрос на русском. У нас оказалось всё проще: никаких тебе номеров поддержки, сразу к делу.
результат выдачи русского гугла
Интересно, как именно происходит добавление подобного ответа. В гугле там соображают или кто-то из представителей отдельной страны с ними связывается и договаривается.
Напрашивается следующий вывод: Володям (пользователям сервисов) стоит внимательнее ознакамливаться с информацией об услуге, а Славикам (разработчикам сервисов) стоит отправиться в командировки по всем маршрутам конторы Nлайнз (тестировать свой сервис в реальных условиях).
Может быть не очень корректно писать 2 комментария подряд, но, имхо, они разные, поэтому разделил.
Лично я считаю такой подход хорошим и даже стало интересно самому провести такой собес. Наверное, лучше всего предлагать кандидатам ситуации, которые реально случались на проекте, тогда решение кандидата можно будет сравнить с тем, как эта проблема уже когда-то решилась в реальности. И вот тут может оказаться несколько вариантов:
1. кандидат не додумается ни до какого решения, либо придумает что-то очень плохое вообще не туда;
2. кандидат будет мыслить в верном направлении и либо придет к тому же, - идеальный кандидат, либо ему чего-то не хватит, что тоже его делает отличным кандидатом, у которого еще всё впереди;
3. кандидат придумает решение еще круче.
В третьем варианте возможен даже сценарий, когда придется сказать кандидату: "круто, но наша команда не справилась бы с вашей идеей - вы слишком хороши для нас". Могу как совет предложить сделать чуть больше акцента в статье на том, что цель, наверное, даже любого собеса найти не лучшего, а наиболее подходящего.
Кавычки у слова "любимый" подразумевают, что это плохой ответ? Если так, то почему? =)
Могу я попробовать: странный у него опыт, в котором он не встречался с тестовыми данными, которые разработчики частенько забывают убрать из публичной версии кода.
За правый шифт и двор стреляю в упор!
При десятипальцевом методе печати, если печатаем большую букву (или символ, для которого необходимо зажать шифт), которая находится в зоне ответственности левой руки, тогда зажимаем правый шифт правой рукой и наоборот, если буква в зоне правой руки, тогда зажимаем левый шифт левой рукой. Таким образом использование шифтов, грубо округлив, сводится к 50 на 50.
По поводу Scroll Lock лично я не вижу проблемы. Ребята, которые пользуются консолью и предпочитают без мыши, рано или поздно приходят к освоению vim (там можно скроллиться вверх/вниз также как описано в статье), после чего их жизнь меняется только в лучшую сторону, и Scroll Lock нервно курит в стороне. В продуктах JetBrains можно вернуться на предыдущее место (это пример, что в софте бывают и альтернативы не хуже Scroll Lock), а в остальном упомянутом софте как бы без мыши не обойтись в любом случае, а для достаточно редких случаев посмотреть, что там выше, не теряя текущей позиции, можно уже и до мыши дотянуться.
Но я наоборот старался подвести логическую цепочку к тому, что анализ не нужен - было бы интересно увидеть стату, но она ничего кроме удовлетворения интереса не даст сообществу, зато статья из разряда "Как написать полезную статью и не выгореть после прочтения комментариев к ней" потенциально могла бы решить (или поспособствовать ее решению) обозначенную проблему и была бы полезна сообществу.
По моему субъективному мнению комментарии на хабре весьма сбалансированы и частенько бывают полезнее самой статьи. Может я уже научился игнорировать левак, а может действительно на хабре не всё так плохо. Но советы авторам и всем остальным, кто мог бы "вступаться" за авторов статей и знать, когда корректно ставить минус комментарию, имхо, лишними не были бы.
Я так понял статья - это что-то вроде попытки обратить внимание сообщества на проблему. Может быть я плохо читал, но я не совсем до конца понял проблему, поэтому хотелось бы уточнить: речь о том, что бывают ситуации, когда неквалифицированные или недостаточно квалифицированные в вопросе люди оставляют комментарии, которые "отпугивают" авторов, так?
И предложение для решения этой проблемы - написать парсер? Допустим, у автора не хватает знаний или времени на написание парсера, но вот я и не вижу конкретного предложения по алгоритму. Сам же могу сказать, что я замечаю в IT сообществе проблему, что есть люди с очень неприятной комбинацией отсутствия достаточной квалификации в вопросе, но наличия уверенности в обратном, которые своим мнением могут "отпугивать" толковых спецов и было бы интересно пересчитать таких персонажей, но как это сделать очень хороший вопрос.
Подсчет мог бы дать общее представление о том, сколько таких, какая вероятность наткнуться, но уже сейчас без всяких анализов можно сказать, что их больше нуля и на пути каждого растущего спеца или автора наверняка такие попадутся не раз, так что следующей статьей в этом направлении могли бы быть советы, как действовать, когда перед тобой непонятно кто; какие уточняющие вопросы лучше задавать, какие бывают стоп-слова, при которых лучше прекращать общение с этим человеком и т. д.
Вместо того, чтобы предлагать сообществу не писать комментарии лучше предложить сообществу способ их отсеивания.
Как раз интересно посмотреть, как браузер отрендерит эти самые первые 14кб. Вот после прочтения статьи мне стало интересно подготовить заглушку в 14кб для пользователей с плохим интернетом. Как вариант стырить пакеты с wireshark, сохранить в файл, потом открыть в браузере... Но может уже есть готовые более простые варианты для отладки.
А какие есть способы отладки всего это счастья? Могу я как-то научить браузер после загрузки первых 14кб останавливаться, чтобы посмотреть, что получилось? И заодно узнать, отдает ли веб-сервер 14кб или больше в качестве первой пачки.
Даже очень =) Накатилась Bolt CMS без приключений, админка похожа, в доке вижу есть секция про ContentTypes, в которой практически все те же типы полей присутствуют, что в Grav. Но не увидел в документации и настройках ничего про формы (пользовательские), например, не нашел настроек smtp, чтобы отправлялись письма от CMS.
Да, то открываются, то нет (по крайней мере в моем случае). На githubstatus.com "partial outage".
И страницы, которые хостятся на github pages недоступны =\
Столько текста лишь бы не признавать PHP лучшим языком ;)
Выходит, эксперимент показал, что собаки умеют распознавать бесполезные эксперименты людей и подыгрывать им.
Побочной фичей внедрения камеры контроля в машину может быть и контроль того, кто находится за рулем, как минимум чтобы это был хотя бы один и тот же человек для одной машины.
Интересно, как именно происходит добавление подобного ответа. В гугле там соображают или кто-то из представителей отдельной страны с ними связывается и договаривается.