Следует также отметить, что в режиме Advanced Google Closure Compiler может угробить работоспособность кода сотней разных способов. Хотя да, сжимает при этом впечатляюще.
Что касается минимификации css — подход Яндекса с их BEM'ом мне кажется наиболее интересным, поскольку позволяет сжимать не только содержимое css, но и сами классы-идентификаторы.
В целом, на мой взгляд тест показывает только то, что особой разницы между минимификаторами в тестируемой конфигурации нет, а значимый результат даёт только глубокая интеграция с соответствующими инструментами.
На моём опыте в известных книгах, посвящённых тайм-менеджменту и сопутствующим проблемы (наиболее ценное кмк — Стивен Кови), именно вопрос энергии раскрыт недостаточно. То есть явно утверждается, что она есть, но не даётся конкретных методик классификации, измерения и управления — только общие слова. Спасибо за перевод, книги Тони Шварца судя по всему стоят прочтения.
В целом же ncix верно заметил, что без постановки правильных целей «энержи-менеджмент» поможет разве что больше пробежать внутри колеса — поэтому эта теория — далеко не первое, во что надо погружаться в области self improvement'а.
Вообще говоря даже надёжность и свежесть субъективны. В смысле за 3 года использования Арча на нескольких компьютерах (небольшой сервер, ноут — для всего включая медиа, жирная рабочая станция) с проблемами от ненадёжности софта из-за свежести (вида недостаточно протестировано) так и не встретился. Тогда как проблем вида «эта фигня не поддерживается в ядре/в несвежем модуле видеокарты» — довольно много.
Идите в мир Archlinux'а — там комьюнити заметно демократичнее (на моём опыте, в багтрекере быстро отвечают, предложенные патчи быстро попадают в test-репозитории), плюс свои пакеты можно самостоятельно заливать на AUR, чтобы после проверки быть доступным всем пользователям. Из-за этого на моём опыте подобные проблемы с неочевидными зависимостями от ядра решаются гораздо раньше.
Такое чувство, что вы живёте в мире розовых пони. У веб-сайтов не должно быть доступа к личным сообщениям и прочим «расширенным» методам api — иначе это будет массово эксплуатироваться, вне зависимости от жёсткости контроля и степени открытости кода сайта. Те методы api, которые с оговорками можно давать другим веб-сайтам, даются узкой группе доверенных компаний — это единственный хоть сколько-то работающий способ контроля.
Что касается «злобных разработчиков мобильного приложения», они могут банально слать с вашего телефона платные СМС — поэтому там пользователи заметно внимательнее смотрят на степень доверенности приложения, чем пользователи очередного сайта, где есть удобная регистрация/авторизация через соц.сети.
Если вам действительно хочется сделать «уникальный» «инновационный» веб-сервис, вы можете попросить пользователя копировать адресную строку c blank.html, или сделать плагины к браузерам.
Вы поймите простую вещь: подобные ограничения делаются не назло разработчикам, а из соображений заботы о пользователях и уменьшения нежелательных для пользователя событий. Раньше ограничений было гораздо меньше: я думаю, почти все помнят нашествие спама из приложений на все стены, закончившееся баном Лицемера 2 года назад (http://roem.ru/2011/02/02/addednews18833/) и закрытием таких возможностей.
Пользователи вообще не склонны читать ограничения, которые выставляет приложение, поэтому для доступа к «расширенному» API необходимо ставить жёсткие ограничения, как минимум чтобы не было эксплуатации социальных связей со стороны приложения, а то и более жёстких вещей типа сбора приватных данных из пользовательской переписки.
Там перечислены разноплановые вопросы. Вопросы про массивы — просто показатель опыта и того, что человек разбирался в причинах проблем. Безусловно, знание этого «ничего не доказывает», просто очень хорошо коррелирует с опытностью человека в технологии и желании разбираться в ключевых особенностях.
Вопросы про экранирование — показатель того, что человек знает, как работает та или иная технология, и умеет решать поставленные задачи; кроме того, экранировать данные надо не только для запросов к БД, но и для вывода в html.
Это эффект Даннинга-Крюгера в чистом виде — людям не хватает профессиональной квалификации, чтобы понять, насколько у них всё плохо, в результате чего сильно завышают профессиональную самооценку, что отражается в том числе на зарплатных ожиданиях. Кроме того, немало таких «программистов» большей частью делали говносайты на друпалах и джумлах.
Теоретически — да, на практике в контексте реальных физических законов вы просто физически не можете приложить сильно большую силу, чем та, которую вы прикладываете при обычном спуске вниз «рывками». Поэтому вы либо упадёте вместе с камнем, либо не сможете его уронить. Плюс, сбрасывать в горах большие камни — заведомо плохая идея.
> Привязав веревку на уступе, вы можете использовать рычаг градуса веревки и собственного тела с отвесом горы.
Тут кстати ситуация обратная, в случае верёвки оборот вокруг любого блока (здесь — уступа) в разы уменьшает силу.
То есть, создание хеша — линейная от количества элементов задача. На масштабах исходной задачи (n > 10^5) асимптотика значительно проявляется, тем более что у простых хешей «константа» низкая. И, вы не поверите, именно это позволяет эффективно работать бесчисленному количеству nosql решений, в том числе распределённых.
На мой взгляд, вы зря получили it-вышку.
Смотрите: сверху привязывается 27-метровый кусок с петлёй снизу. Через эту петлю просто пробрасывается верёвка, без завязывания (лучше несколько раз, для уменьшения необходимой силы для удержания веса тела). Эта 53-метровая верёвка с одной стороны привязывается к телу, а другая сторона используется для аккуратного спуска. Уже на уступе эта верёвка просто вытаскивается через петлю, и привязывается к уступу.
По техническим вопросам, кмк, проверяется способность человека за ограниченное время решать хоть сколько-то непростые вопросы в знакомой ему области. Если он может — скорее всего он может научиться тому что нужно в другой области.
Мне кажется, вы удивитесь, насколько много людей с большим опытом и зарплатными ожиданиями не знают php на достаточном для работы уровне — не ловят момент, когда вместо isset нужен array_key_exists, не знают разницы между array_merge и +, не знают, как работают ключи в массивах, не слышали про continue/break с числом, не умеют работать с mb_ функциями, очень плохо знают regexp'ы. Да что уж там, даже нормально заэкранировать строку не могут.
И это не говоря о более сложных вещах, типа понимания блокировок (и, как следствие, знания, как будет работать страничка вида «session_start();sleep(10);»), понимание атомарности, очередей и отложенного выполнения задач. Хотя да, «паттерны» знают, но почему-то в реальной реализации даже псевдокодом сильно путаются.
Эти знания у меня были ещё в студенческие годы, до начала коммерческой разработки. Называть меня тогда «отличным специалистом» — несколько опрометчиво — опыт всевозможных ACM мало кому на самом деле нужен, а указанный уровень знания sql на практике тренировался до достаточного для собеседований уровня меньше чем за неделю.
Кстати, уточните, пожалуйста, условия второй задачи — интересно же.
Какие-то у вас подозрительно простые задачи.
Про верёвку: можно кусок в 25 метров привязать сверху, и использовать как блок для оставшейся верёвки для спуска на выступ, и её же использовать для обычного спуска на оставшиеся 50 метров. Если гора совсем отвесная, задача ещё проще: можно резать/развязывать верёвку и падать как на тарзанке.
Первая задача: любой подходящий хеш (O(n)). Для sql — знание union.
Вторая задача недостаточно корректна сформулирована: нет формального определения «частичной повторяемости», не описаны ограничения на количество определений для одного слова.
Если речь о префиксах, задача банальна и сводится к обрезанию определения до первого слова, что даже для всяких mysql элементарно.
На мой взгляд, наиболее эффективно на собеседовании просто задавать человеку вопросы по той теме, которой он занимался, чтобы понять глубину погружения и умения понимать, ну и просто уровень мышления. Само собой, начиная от банальных вопросов, для быстрого отсеивания людей, оказавшихся на собеседовании случайно…
В своё время у меня не получилось завести дебаг в Intellij IDEA — пришлось разбираться в gdb. Как ни странно, ничего страшного не случилось — gdb вполне прост и удобен.
Требования — в посте. Вы предложили методы решения соответствующих требований. Создавать технологических процесс действительно необходимо, просто хоть сколько-то квалифицированные программисты и их непосредственных технический менеджмент и сами хорошо понимают, как _лучше_ в конкретном случае решать соответствующие требования, и почему эти общие требования важны и удобны. Именно поэтому тех.диру может быть достаточно просто сформулировать требования и вместе с техническим персоналом выбрать оптимальное решение, которое внедрять уже совместными усилиями, а не личной волей тех.дира, который лучше подчинённых знает, как они должны работать.
Извините, просто наелся такого неквалифицированного менеджмента с завышенным самомнением и непониманием принципов совместной работы.
Чувствуется советский подход: «зачем спрашивать подчинённых, когда я лучше знаю, что нужно делать». Задача руководства, в первую очередь,— определиться с требованиями, следить за их исполнением и корректировать, где это требуется. И вы не поверите, если конкретное решение разделяют исполнители (потому что они участвовали в принятии решения) — оно внедряется куда эффективнее и с гораздо большим энтузиазмом.
Именно в ответ на таких «менеджеров» и «руководителей» появляются движения типа такого: programming-motherfucker.com
Есть одна область программирования, которую прекрасный Uncle Bob успешно игнорирует — прототипирование. Там нужны именно ручные тесты, качество и производительность кода не имеет особого значения, тогда как сроки крайне важны. Это может быть стартап, выпускающий новый продукт, или эксперименты у крупного веб-продукта на небольшой аудитории.
Отказ от прототипирования — заведомо показатель некомпетентного технического руководителя. Другой вопрос, что в случае успеха прототип должен быть допилен до адекватного состояния, что, к сожалению, делается далеко не всегда, и это уже прямая вина технического руководства.
Что касается минимификации css — подход Яндекса с их BEM'ом мне кажется наиболее интересным, поскольку позволяет сжимать не только содержимое css, но и сами классы-идентификаторы.
В целом, на мой взгляд тест показывает только то, что особой разницы между минимификаторами в тестируемой конфигурации нет, а значимый результат даёт только глубокая интеграция с соответствующими инструментами.
В целом же ncix верно заметил, что без постановки правильных целей «энержи-менеджмент» поможет разве что больше пробежать внутри колеса — поэтому эта теория — далеко не первое, во что надо погружаться в области self improvement'а.
vk.com — работает
m.vk.com — работает
Питер, Interzet.
Когда заблокируют https, сайтам с авторизацией через vk будет невесело. Остальным, видимо, придётся временно переходить на мобильную версию.
Что касается «злобных разработчиков мобильного приложения», они могут банально слать с вашего телефона платные СМС — поэтому там пользователи заметно внимательнее смотрят на степень доверенности приложения, чем пользователи очередного сайта, где есть удобная регистрация/авторизация через соц.сети.
Если вам действительно хочется сделать «уникальный» «инновационный» веб-сервис, вы можете попросить пользователя копировать адресную строку c blank.html, или сделать плагины к браузерам.
Пользователи вообще не склонны читать ограничения, которые выставляет приложение, поэтому для доступа к «расширенному» API необходимо ставить жёсткие ограничения, как минимум чтобы не было эксплуатации социальных связей со стороны приложения, а то и более жёстких вещей типа сбора приватных данных из пользовательской переписки.
Вопросы про экранирование — показатель того, что человек знает, как работает та или иная технология, и умеет решать поставленные задачи; кроме того, экранировать данные надо не только для запросов к БД, но и для вывода в html.
> Привязав веревку на уступе, вы можете использовать рычаг градуса веревки и собственного тела с отвесом горы.
Тут кстати ситуация обратная, в случае верёвки оборот вокруг любого блока (здесь — уступа) в разы уменьшает силу.
На мой взгляд, вы зря получили it-вышку.
По техническим вопросам, кмк, проверяется способность человека за ограниченное время решать хоть сколько-то непростые вопросы в знакомой ему области. Если он может — скорее всего он может научиться тому что нужно в другой области.
И это не говоря о более сложных вещах, типа понимания блокировок (и, как следствие, знания, как будет работать страничка вида «session_start();sleep(10);»), понимание атомарности, очередей и отложенного выполнения задач. Хотя да, «паттерны» знают, но почему-то в реальной реализации даже псевдокодом сильно путаются.
Кстати, уточните, пожалуйста, условия второй задачи — интересно же.
Про верёвку: можно кусок в 25 метров привязать сверху, и использовать как блок для оставшейся верёвки для спуска на выступ, и её же использовать для обычного спуска на оставшиеся 50 метров. Если гора совсем отвесная, задача ещё проще: можно резать/развязывать верёвку и падать как на тарзанке.
Первая задача: любой подходящий хеш (O(n)). Для sql — знание union.
Вторая задача недостаточно корректна сформулирована: нет формального определения «частичной повторяемости», не описаны ограничения на количество определений для одного слова.
Если речь о префиксах, задача банальна и сводится к обрезанию определения до первого слова, что даже для всяких mysql элементарно.
На мой взгляд, наиболее эффективно на собеседовании просто задавать человеку вопросы по той теме, которой он занимался, чтобы понять глубину погружения и умения понимать, ну и просто уровень мышления. Само собой, начиная от банальных вопросов, для быстрого отсеивания людей, оказавшихся на собеседовании случайно…
Извините, просто наелся такого неквалифицированного менеджмента с завышенным самомнением и непониманием принципов совместной работы.
Именно в ответ на таких «менеджеров» и «руководителей» появляются движения типа такого:
programming-motherfucker.com
Отказ от прототипирования — заведомо показатель некомпетентного технического руководителя. Другой вопрос, что в случае успеха прототип должен быть допилен до адекватного состояния, что, к сожалению, делается далеко не всегда, и это уже прямая вина технического руководства.