Картинки можно выравнивать таК, как хочется автору топика. Проблем с этим не испытывал особо.
С отступами — мысль дельная. Я отступы выставлял переносами строк
Дополнительно, очень хочется видеть список «топ 5 комментариев» по рейтингу, для топиков, где больше 100 комментариев.
Очень огорчает, что трансляция контента на «пульт» есть только в топовых моделях телевизоров (В моём 6ххх — ещё нет) и что нормальной клавиатуры тоже нет. Пользоваться тем же youtube с телевизора становится очень сложно (без специального ютубовского же приложения).
В остальном — и идея, и реализация мне нравятся. В будущих версиях хочется получить виджеты с отдельными функциями, чтобы не грузить всё приложение. Например, виджет регулировки громкости.
дополню сам себя: Конкуренты уводят клиентов друг у друга. Как правило, это происходит, потому что клиенты не видят разницы между продуктами — продукты не обладают индивидуальностью.
На самом деле, клиентов уводят, как раз потому что последние видят разницу ;) И брендинг тут не всегда играет ключевую роль. Хотя, конечно, помогает заинтересовать на первом этапе.
с отключенным явоскриптом в статье на сайте журнала видно больше текста. Не знаю уж с чем это связано. (Хотя я может не нашёл, где листать страницы. У меня вообще проблемы с интерфейсами...)
Транзисторы процессора Intel Core Duo размещены на кристалле размером 90,3 мм², то есть на одном квадратном миллиметре (площадь поверхности кончика стержня шариковой ручки) в среднем расположено 1,7 млн. транзисторов. А в некоторых блоках микропроцессора – таких, как, например, кэш-память – плотность транзисторов достигает даже 10 млн. штук на квадратный миллиметр.
В свете вышеприведённых данных, хочется ещё почитать про то, сколько трубок требуется на 1 транзистор (или сколько транзисторов в одной трубке). А то достижение пока на 2 порядка лучше предыдущего, но всё равно сомнительное.
PS IBM вызывает восхищение: коммерческая контора, научный вклад которой невероятно велик!
В таком виде только в zsh возникают «нюансы»: команды «echo a» не существует.
Надёжнее делать:
a="echo a";
eval $a
С использованием eval проблем нет ни в одном из шеллов (ну, насколько мне известно...;)
При использовании команды sudo в скриптах, почти всегда лучше использовать ключ -i: в неинтерактивном режиме, большая часть шеллов не source'ит rc и profile файлы, что может привести к проблемам в работе софта.
Попытаюсь вспомнить ещё чего-нибудь «забавного» и допишу.
Я не понимаю, почему я должен отказываться от вопросов по теории. Почему я не могу спросить, чем буфер отличается от кэша или протокол от интерфейса? Я понимаю, что не все это знают. Но если человек утверждает, что знает сети, например, то я бы предпочёл работать с человеком понимающим эту разницу. Да, в таких вопросах нет места полёту фантазии. Но фантазии не бывает на пустом месте. Обычно, я хочу работать с людьми, чей полёт фантазии опирается на крепкие крылья теории.
С другой стороны, да, вы правы, задавать вопросы только по теории — неправильно. На разные вакансии вопросы должны быть разные. Где-то нужно спрашивать о типовых решениях в архитектуре. Где-то об утилитах консоли. А где-то достаточно, чтобы человек был сообразителен или усидчив.
Вернусь к первой фразе вашего поста: кого мы собеседуем? В общем случае ваши советы… могут оказаться не совсем актуальными ;) Хотя в частностях — вполне приемлимы.
Возможно, да. Но я бы тогда сформулировал вопрос как «какие меры вы можете предложить для снижения плотности потока в часы пик» или как-то иначе. До тех пор, пока человек не понимает, чего спрашивает, его нужно просить уточнить формулировку. Это можно сделать вежливо, пояснив двусмысленность вопроса или осветив возможные варианты ответа. А можно попросить уточнения формулировки более грубым способом — точным ответом, которого человек гарантированно не ожидает.
Я использую оба способа в разных ситуациях. Но чаще всего, после первого, очевидно неверного ответа, перехожу к первому варианту поведения. Хотя если человека раздражает, то стараюсь избегать шуточек ;)
В любом случае, по практике собеседований с двух сторон, я бы сказал, что ваш четвёртый пункт — самый важный. Он должен быть первым.
На мой вкус, большая часть проблем предприятий в том, что руководство врёт само себе. В частности — в вопросах найма сотрудников. Посмотрите на большую часть вакансий на каком-нибудь hh: в своей профессиональной области я вряд ли претендую на 10% из них. При хорошем опыте работы в 7 лет. Но по факту, я пройду собеседование почти на любую из них. Почему? Потому что требуют не то, что реально нужно. И в личной беседе это становится очевидно.
Как решить эту проблему? Чётче формулировать требования к сотрудникам. Если вам нужно поддерживать 100500 костылей в старом коде, это одно. Если писать что-то с нуля — это другое.
Если вы понимаете, что в формулировках запросов у вас одно, а нанимаете вы другое, то попросите у кого-нибудь помощи.
Тоже самое касается вопросов (ваш третий пункт): если вы спрашиваете одно, а в реальности человек будет заниматься другим — бросайте задавать вопросы, попросите помощи в их формулировке у других.
Второй пункт даже спорить не буду: если вам нужно решить задачу А, вы ищете под это специалиста. Если он справляется с этой работой — хорошо. Если работа измениться, вы сможете сменить специалиста, если этот «не потянет». Хватит врать себе и верить, что есть бесконечно талантливые люди, способные на всё.
Ваш вопрос — тоже теория. Только в несколько другой области («создание веб-приложения» может подразумевать разработку всей архитектуры решения). Подобные задачи, обычно, решаются «в общем виде»: «запросы приходят сюдя в таком-то виде, туда в таком-то виде, а в кэшах вот тут, тут и тут у нас хранится то, то и то». И только после проработки этого общего решения начинается практика в виде «запросы принимает mysql, кэши построим на апаче».
В данном случае, можно сослаться на теорию массового обслуживания, как фундаментальную. Но и сама архитектура штука во многом теоретическая.
Вы зря не указали, кого собеседуют.
Знание теории и умение применять типовые решения — разные вещи. Зачастую, вопросы по теории — важны. А разница в версиях продуктов как раз очень даже практика.
Например:
Теория: — В чём преимущество множества нитей над множеством процессов в работе одной программы? В чём недостатки? Как можно организовать работу программы со множеством клиентов в одной ните исполнения?
Практика: — Чем апач префорк отличается от апач worker? А чем они отличаются от nginx?
Знающий ответ на первые вопросы, легко ответи на остальные.
Вообще, текст откровенно слабый. Очень напоминает злость непрошедшего собеседование. Из всего текста я вынес себе мысль «надо посмотреть moneyball».
Скажите, вы точно не заваливали собеседований в последнее время?
Вот теперь всё встало на свои места ;) Просто вместо охлаждения воды в чиллерах, гоняют воду из бассейна. Вполне логично и теперь более-менее ясно. (Остались нюансы с переключением контуров туда-сюда, но это уже «технические подробности». Спасибо за пояснение.
С отступами — мысль дельная. Я отступы выставлял переносами строк
Дополнительно, очень хочется видеть список «топ 5 комментариев» по рейтингу, для топиков, где больше 100 комментариев.
В остальном — и идея, и реализация мне нравятся. В будущих версиях хочется получить виджеты с отдельными функциями, чтобы не грузить всё приложение. Например, виджет регулировки громкости.
Конкуренты уводят клиентов друг у друга. Как правило, это происходит, потому что клиенты не видят разницы между продуктами — продукты не обладают индивидуальностью.
На самом деле, клиентов уводят, как раз потому что последние видят разницу ;) И брендинг тут не всегда играет ключевую роль. Хотя, конечно, помогает заинтересовать на первом этапе.
В свете вышеприведённых данных, хочется ещё почитать про то, сколько трубок требуется на 1 транзистор (или сколько транзисторов в одной трубке). А то достижение пока на 2 порядка лучше предыдущего, но всё равно сомнительное.
PS IBM вызывает восхищение: коммерческая контора, научный вклад которой невероятно велик!
делают одно и то же. Последнюю переменную можно использовать для всяких mv дополнительно.
Ещё мелкая «полезняшка», экономящая время на длинных именах файлов:
На время отладки можно добавить ключ -x к шабангу:
Эквивалентно set -x.
В таком виде только в zsh возникают «нюансы»: команды «echo a» не существует.
Надёжнее делать:
С использованием eval проблем нет ни в одном из шеллов (ну, насколько мне известно...;)
При использовании команды sudo в скриптах, почти всегда лучше использовать ключ -i: в неинтерактивном режиме, большая часть шеллов не source'ит rc и profile файлы, что может привести к проблемам в работе софта.
Попытаюсь вспомнить ещё чего-нибудь «забавного» и допишу.
С другой стороны, да, вы правы, задавать вопросы только по теории — неправильно. На разные вакансии вопросы должны быть разные. Где-то нужно спрашивать о типовых решениях в архитектуре. Где-то об утилитах консоли. А где-то достаточно, чтобы человек был сообразителен или усидчив.
Вернусь к первой фразе вашего поста: кого мы собеседуем? В общем случае ваши советы… могут оказаться не совсем актуальными ;) Хотя в частностях — вполне приемлимы.
Я использую оба способа в разных ситуациях. Но чаще всего, после первого, очевидно неверного ответа, перехожу к первому варианту поведения. Хотя если человека раздражает, то стараюсь избегать шуточек ;)
В любом случае, по практике собеседований с двух сторон, я бы сказал, что ваш четвёртый пункт — самый важный. Он должен быть первым.
На мой вкус, большая часть проблем предприятий в том, что руководство врёт само себе. В частности — в вопросах найма сотрудников. Посмотрите на большую часть вакансий на каком-нибудь hh: в своей профессиональной области я вряд ли претендую на 10% из них. При хорошем опыте работы в 7 лет. Но по факту, я пройду собеседование почти на любую из них. Почему? Потому что требуют не то, что реально нужно. И в личной беседе это становится очевидно.
Как решить эту проблему? Чётче формулировать требования к сотрудникам. Если вам нужно поддерживать 100500 костылей в старом коде, это одно. Если писать что-то с нуля — это другое.
Если вы понимаете, что в формулировках запросов у вас одно, а нанимаете вы другое, то попросите у кого-нибудь помощи.
Тоже самое касается вопросов (ваш третий пункт): если вы спрашиваете одно, а в реальности человек будет заниматься другим — бросайте задавать вопросы, попросите помощи в их формулировке у других.
Второй пункт даже спорить не буду: если вам нужно решить задачу А, вы ищете под это специалиста. Если он справляется с этой работой — хорошо. Если работа измениться, вы сможете сменить специалиста, если этот «не потянет». Хватит врать себе и верить, что есть бесконечно талантливые люди, способные на всё.
В данном случае, можно сослаться на теорию массового обслуживания, как фундаментальную. Но и сама архитектура штука во многом теоретическая.
Знание теории и умение применять типовые решения — разные вещи. Зачастую, вопросы по теории — важны. А разница в версиях продуктов как раз очень даже практика.
Например:
Теория: — В чём преимущество множества нитей над множеством процессов в работе одной программы? В чём недостатки? Как можно организовать работу программы со множеством клиентов в одной ните исполнения?
Практика: — Чем апач префорк отличается от апач worker? А чем они отличаются от nginx?
Знающий ответ на первые вопросы, легко ответи на остальные.
Вообще, текст откровенно слабый. Очень напоминает злость непрошедшего собеседование. Из всего текста я вынес себе мысль «надо посмотреть moneyball».
Скажите, вы точно не заваливали собеседований в последнее время?