В компаниях, где я работал, при подаче заявок на участие в тендере часто прикрепляли сертификаты компании, сертификаты и дипломы сотрудников. Большей частью это делается, чтобы напустить пыли в глаза, но тем не менее, какая-то польза от дипломов есть.

странно, что в подобных крупных компаниях используется софт типа CCleaner

Судя по статье, Cisco Talos обнаружили троян в CCleaner в результате тестирования своей системы обнаружения эксплойтов.
Или вы о другой компании говорили?

Или немного покороче:

a.hasOwnProperty(key) && a[key] || 'defaultValue';

Правда читаемость кода…

Позанудствую немного.
В словосочетаниях «атомная бомба», «ядерная бомба», «термоядерная бомба» прилагательные определяют тип реакции, который происходит при подрыве (реакции ядерного распада / ядерного синтеза).
Обычные бомбы относятся к «химическим», где происходят реакции разложения или окисления.
В будущем, возможно, появится какая-нибудь «аннигиляционная бомба» на принципе аннигиляции вещества/антивещества.

Очень показательные комментарии директора (!!!) компании.
Думаю, каждый, кто с вами сотрудничает или вдруг (внезапно) надумает сотрудничать, после прочтения ваших сообщений сделает для себя однозначные выводы. Выводы о вас как человеке и вашей конторе в целом.
Вы вот все пылите яркими фразами, оперируете какой-то воровской лексикой, но сами-то ведете себя не «по-пацански», не «по понятиям».

NaN === NaN // -> false

Мой опыт подсказывает, что почти во всех ЯП NaN («не число») не равно самому себе и для такой ситуации предусмотрены отдельные методы:

Object.is(NaN, NaN); // -> true

Аналогичная ситуация в ЯП обстоит с +0 и -0:

+0 === -0 // -> true

но:

Object.is(+0, -0); // -> false

А если поставить себя на место преподавателя — как оценить знания сотен учеников? Самое очевидное, по выполненному ДЗ, по устным ответам на уроках, по участию в олимпиадах… Увы, но лично пообщаться с сотней учеников и узнать их сильные стороны не всегда получается.

Не соглашусь, nikitasius предлагает использовать ssh туннель до своего vds/vps, на котором запущен прокси (тот же squid). По факту о вашем закрытом прокси знает только хостер и провайдер vds. Ваш же провайдер видит только шифрованный ssh траффик — а чем вы там занимаетесь ему неизвестно. Пока что закона об ограничении ssh нет, и надеюсь не будет.

Если не затруднит, поясните, а в чем профит от инлайн svg? По мне, инлайн svg — это как вставить картинку через data/image. Да, уменьшается кол-во запросов к бекенду и для небольших изображений браузер скорее всего быстрее отрисует область… Но вместе с этим уменьшается гибкость решения, и при желании изменить иконку во всех местах проекта, придется немало покопаться…

Вброшу свои пару мыслей на вентилятор:
1. Любой фреймворк создается для решения какого-то определенного множества задач. Если ваша задача не входит в рамки фреймворка, то это проблема не фреймворка, а вашего выбора.
2. Использовать какой-то фреймворк или не использовать, это как выбор религии — никто не в праве навязывать вам выбор и никто не в праве порицать ваш выбор.

Может быть у вас найдется время написать статью на GT про разводку электрики в доме, хорошие практики, про скрытые грабли и прочее? Думаю, многим это будет интересно (мне вот точно интересно).

Вброшу, так сказать, свои пару слов:
1. Начиная с servlet-api 3.0, файл web.xml стал необязательным и указание сервлетов, фильтров, слушателей осуществляется соответствующими аннотациями — WebServlet, WebFilter, WebListener и т.д.
2. Если нужно определить синонимы урлов страниц (aka чистые ссылки), то это стоит выделить в отдельный сервлет или вовсе переложить обязанность на фронтенд веб-сервер (например, nginx).
3. По поводу выкладки на сервер. На продуктивной среде автодеплой war-ников в целях безопасности обычно выключают, в server.xml прописываем свои приложения, а выкладку делаем руками или шелл-скриптами. Для тестовой (часто обновляемой) среды можно использовать CI систему.

>> Например, если вам нужен точный прогноз погоды, где учитывается огромное количество факторов.
Видимо, тут имеется в виду сервис Яндекс.Погода. Без обид ребята, но прогноз погоды работает далеко от категории «точно». Порой даже постфактум Яндекс.Погода показывает неверные данные. Хотя, полагаю все дело в самой погоде — она такая непредсказуемая.

Внесу в дискуссию свою лепту.
1. У ММВБ есть открытое api для доступа к котировкам и историческим данным.
Но, к сожалению, по бесплатной подписке котировки идут с задержкой, а исторические данные ограничены.
А подписка для получения онлайн котировок стоит весьма ощутимо для начинающего трейдера.
2. Бесплатных api для доступа к котировкам ММВБ увы нет и, скорее всего, не будет, поскольку распространение торговых данных ограничено копирайтом ММВБ.
3. Для получения онлайн котировок можно использовать FIX протокол, если торговая система имеет такую возможность. Quik предоставляет доступ через FIX, но этот протокол должен поддерживаться и брокером, через которого трейдер выходит на биржу. Опять же, увы, но чуть более чем никто из брокеров не поддерживает FIX протокол.
4. Еще вариантом экспорта онлайн котировок может служить мост из терминала в свою систему. Например, тот же Quik предоставляет экспорт по DDE/ODBC, или же можно написать простенький скрипт на QLua, который отсылает данные по сокетам. Самый большой минус такого экспорта — инструменты для экспорта должны быть выбраны вручную.
P.S.: Люди возмущены отсутствием читаемости и гибкости кода, и я с ними солидарен. Сам писал такой экспорт данных. По сути, функция должна принимать в качестве аргументов только то, что ей необходимо знать. А ей необходимо знать только: код эмитента, шаг времени, период дат для выгрузки. Все остальные параметры являются служебными и их стоит скрыть от прикладного программиста.

Ну, почему же никому не интересны? А если при ежемесячном доходе в 50к вы тратите в магазинах 500к, то налоговой, думаю, это будет очень интересно.

без обид, но я не пойму, в чем смысл статей об устаревших технологиях… на мой взгляд такие статьи не только бессмысленны, но и вредны… наивный дурачок зайдет на хабр, увидит статью по технологиям 15-летней давности, подумает: «Ага, раз пишут на хабре, то это норма!» — и станет использовать это у себя в коде… :-)

смотрите, если использовать аналогию с плотниками: есть молоток для обивки кожи, есть молоток для забивания гвоздей, есть ювелирный молоток — под конкретную задачу свой инструмент… так же и у нас — под каждое приложение может быть использован свой стек технологий…
если paypal выяснили, что node.js для них оптимальный выбор — это хорошо, вопросов нет…
мой комментарий был акцентирован на то, что представленные графики времени отклика неверно составлены… более показательны были бы графики зависимости latency от bandwidth на всем диапазоне кол-ва запросов — от нулевого до максимального… и при этом стенды испытаний, чтобы были одинаковы…

мы что-то измерили, что-то получили… и выяснилось, что node.js в два раза шустрее java…
шикарный исследовательский подход… особенно радуют выборки — 1 пользователь, 5, 10… серьезно? )))
а если по существу, делать корректные, воспроизводимые бенчмарки — это не просто замерить время вызова одной странички…