Ага-ага, как кризис, так Сони кричат «Ай, дорогой наш Эриксон, спасай компанию или забирай ее себе!», а как стали более-менее хорошие модели выпускать, так сразу «мы бы хотели приобрести активы..»
Зря шведы с ними связались — пока мобильный бизнес был целиком у них, они выпускали отличные модели.
Он самый удобный, потому что следует внутреннему представлению структуры данных. Если итерироваться по ключам, то на каждом шаге придется вызывать хэш-функцию, а на это тратится время и вычислительные ресурсы.
О, да! На деле самая удобная коллекция. Тот факт, что пары ключ-значение идут в предсказуемом порядке, существенно облегчает дебаг. Жаль, что почти никто этой коллекцией не пользуется.
Может быть, все — прагматики? Зачем спорить о применимости шаблона? — ведь в конечном счете все зависит от конкретной задачи. По хорошему да, синглтоны не нужны, но раз уж кто-то решил создать у себя в коде синглтон, пусть уж знает, как правильно это делается — вот тут и пригодится статья.
А как вы собираетесь выдавать инвайты? Наберете сейчас за пару часов энное количество пользователей и закроетесь или будете еще выдавать по чуть-чуть в течение ближайших дней?
Я всегда пользовался мобильной версией SlideShare — она никогда на флеше не работала — просто слайды подгружались картинками. Не совсем понятно, зачем они вообще начали использовать флэш.
Интересно сравнение производительность HiPE по сравнению с BEAM. Некоторое время назад читал мнение о том, что HiPE — пока что не более чем hype — раскрученная идея, но недостаточно хорошая реализация.
Вообще распространенное заблуждение, что раз язык конкурентный и создан для soft realtime систем, то значит, он быстрый. На деле Эрланг — середнячок, не конкурент C++, OCaml, или Java. Но его козырь — отказоустойчивость и предсказуемость.
Я думаю, что в mail.ru работают отличные ребята. В свое время меня туда звали, хотя дальше телефонного звонка с их HRом ничего не дошло — на тот момент у меня было предложение поинтереснее.
Уверен, что и проекты там ведутся интересные, и проблем много — а значит, есть над чем работать. Показательно, что несмотря на сильную конкуренцию со стороны Яндекса, Контакта, Одноклассников, Гугла и Фейсбука, Мейлру остается на плаву и не теряет своих позиций. Это уже что-то — посмотрите на тот же Рамблер.
Недавно анонсировали похожий проект — Opa, даже писали о нем на Хабре. Есть ряд отличий — у них специализированный для веба язык, интегрированная база данных и вебсервер. Но в целом ощущение остается таким же — декларативный код с pattern matching — для вебразработки вполне удобно. Молодцы.
Единственное, с чем я не согласен, так это с попыткой заменить JavaScript на что-то другое. В реальной жизни такие идеи не срабатывают, т.к. создатели своих языков не достаточно полно учитывают специфику JS и браузеров. Исключением можно назвать разве что CoffeeScript. Он обходит все скользкие моменты JS и производит вполне дебагоспособный код, проходящий все проверки на «вшивость» — JSLint, es5 strict mode.
Если б я создавал язык для компиляции в JS сегодня, я бы не заморачивался и стал бы компилировать в CoffeeScript, а результат — уже в JS.
Да, это ясно, но ведь список будет какое-то время жить в рантайме, по нему нужно будет итерироваться, и с учетом того, что мы добавляем туда элементы, итерироваться придется неоднократно. А это довольно дорогая операция по сравнению с ArrayList'ом.
Если нам так уж нужно, чтобы элементы находились в определенном порядке, не лучше ли формализовать этот порядок в виде компаратора и использовать SortedSet?
А если порядок не нужен, почему бы не добавлять элементы в конец списка?
А если ожидаемое количество элементов известно, не проще ли создать ArrayList с заданным первоначальным размером?
А если все-таки, несмотря на все вышеперечисленные предложения, больше подходит LinkedList, не стоит ли посмотреть в сторону B-деревьев?
Есть только один сценарий, при котором LinkedList уместен — когда он стоит в основе реализации очереди, используемой несколькими потоками.
На заметку: интерфейс Opera Mini 5 и Opera Mobile 10 проектировался именно из соображений того, что телефон управляется одной рукой. Откройте браузер, держа телефон провой рукой. Если у вас не слишком короткие пальцы и если у вас не пятидюймовый лопатофон (просьба не обижаться, я сам обожаю лопатофоны), то вы заметите, что под большим пальцем оказывается кнопка «Назад», она же «Zoom out». По результатам исследований именно ее чаще всего нажимают пользователи. Если же повернуть большой палец так, чтобы скролить страницу, то при скроллинге под ним оказывается кнопка быстрого перемещения. Ее ввели, когда было решено избавиться от полосы с title на верху экрана и дать больше места для контента. Да и форму кнопок на Speed Dial подобрали так, чтобы было удобнее пальцем ткнуть. В том же Дельфине кнопки вытянуты в узкие прямоугольники — на маленьком экране можно промахнуться.
Типичная сессия пользователя выглядит так: он открывает браузер, выбирает страницу на SpeedDial, затем приближается, если нужно, ткнув на экран. Читает страницу, скроля ее пальцем. Если ему хочется прокрутить ее быстро вверх или вниз, он использует появляющиеся кнопки. Также он может прыгать между отдельными участками страницы, используя кнопку Назад. Когда сеанс закончен, пользователь нажимает Назад и возвращается в Speed Dial. Потом он также может выбрать следующую страницу, и все пойдет по новой. Открытие нескольких табов идет по долгому нажатию, а переключение между ними также производится через кнопку, соседствующую с кнопкой Назад.
Таким образом, большинство действий, связанных с просмотром вебстраниц, можно выполнять одним пальцем, держась второй рукой за поручень в транспорте, например.
В связи со статьей возник вопрос: кто-нибудь в реальном проекте когда-либо использовал LinkedList?
Из своего опыта скажу, что даже в тех случаях, когда он по идее должен был дать прирост в производительности — т.е. большой список с частым удалением и добавлением элементов в середину и начало списка — ArrayList все равно оказывался быстрее.
Объяснение простое: ArrayList внутри себя использует System.arrayCopy — нативную функцию, которая отрабатывает на удивление шустро. В то же время для LinkedList'а приходится переопределять несколько указателей, но это не самое главное. Все эти указатели на предыдущего и следующего обходятся сборщиком мусора. Из-за этого растет время, необходимое для стадии маркинга, а с учетом того, что в одном списке оказываются элементы из разных поколений, вся процедура затягивается еще больше.
В единственный раз, когда LinkedList почти догнал ArrayList по производительности, я решил попробовать PersistentVector из Clojure, и тот оказался в полтора раза быстрее обоих. PersistentVector внутри представляет из себя дерево массивов, поэтому операции вставки приводят к изменению только одного или нескольких сегментов дерева, т.е. одной или нескольким операциям arrayCopy, которая для небольших массивов остается непревзойденной по скорости.
Так что остается ощущение, что LinkedList остается в JDK только для того, чтобы у кандидатов на интервью про его эффективность вопросы задавать.
Нет, это именно статистика посещения их сайта, причем w3schools не имеет никакого отношения к w3c. Также вы должны понимать, что любое обращение к w3schools — моветон. Рекомендуется к прочтению: w3fools.com/
1. Уязвимости подвержены все версии SSL и TLS 1.0. Только TLS 1.1 и TLS 1.2 остались безопасными. Это означает, что чтобы действительно оставаться в безопасности, нужно в настройках IE или Opera убрать галки для SSL и TLS 1.0 и поставить галки для TLS 1.1 и TLS 1.2. НО: после этого почти весь интернет по HTTPS будет для вас недоступным — я не нашел ни одного крупного сайта, который бы поддерживал последние версии TLS, ни Google, ни Facebook, ни PayPal, ни Microsoft, ни Twitter — никто не поддерживает соединений по этим версиям.
2. Эксплойт работает как Man-in-the-middle в сочетании с внедрением JavaScript-кода на страницу. Злоумышленник слушает https-трафик и вносит на страницу клиента JavaScript. Затем этот скрипт продолжает слать запросы по тому же соединению с известным злоумышленнику содержимым. Зная содержимое тела запроса, злоумышленник может расшифровать HTTP-заголовки, в том числе cookie пользователя.
Это означает, все HTTPS-соединения остаются безопасными, если на странице отключен JavaScript.
Таким образом, у пользователей есть два варианта: либо просто продолжать пользоваться интернетом и надеяться, что их не успеет никто взломать, пока проблему не устранят, либо продолжать пользоваться https, но выключить на защищенных страницах JavaScript. Чего не стоит делать, так это выключать в браузере TLS 1.0, оставляя включенным SSL 3 — так вы делаете себя менее защищенным, т.к. для SSL 3 известны и другие эксплойты, а браузеры оставляют его поддержку включенной только из-за того, что в интернете полно сайтов, которые еще не мигрировали на TLS. При создании соединения браузер пытается использовать самый безопасный протокол, и только потом переключается на более ранние протоколы.
Теперь вопрос, почему никто в интернете не пользуется последними версиями TLS протокола. Ответ: потому что его реализации нет в OpenSSL, которым в свою очередь пользуются все серверы: Apache, Nginx и т.п — и браузеры — Chrome, Safari, Firefox. (см. en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Protocol_Support) От том, почему ребята из OpenSSL их не реализуют, мне неизвестно. Зато я знаю, что Opera тоже использует OpenSSL (см opera:about), но в ней также есть своя реализация протоколов TLS 1.1 и TLS 1.2 — которые они по всей видимости не могут передать в руки опен-сорс сообщества.
Вы же понимаете, что в реальной жизни из 100 человек все плохо работать не могут. На деле все происходит так: из 100 человек кредит получат 40, из них 15 человек будут работать хорошо, 20 — плохо, но кредит выплатят, 3 будут переоформлять кредит (увеличивать срок погашения, уменьшать ставку и т.п.), а за двух оставшихся банк получит страховку.
А люди пусть уходят в социальную сферу. Продолжительность жизни растет, а значит все больше и больше пожилых людей нуждаются в медицинских услугах и в уходе. Уже сейчас в странах первого мира жесткая нехватка квалифицированных медсестер, и многие из них за свой труд получают совсем неплохо.
Зря шведы с ними связались — пока мобильный бизнес был целиком у них, они выпускали отличные модели.
* Сам за годы работы ни разу не писал синглтонов.
Вообще распространенное заблуждение, что раз язык конкурентный и создан для soft realtime систем, то значит, он быстрый. На деле Эрланг — середнячок, не конкурент C++, OCaml, или Java. Но его козырь — отказоустойчивость и предсказуемость.
Уверен, что и проекты там ведутся интересные, и проблем много — а значит, есть над чем работать. Показательно, что несмотря на сильную конкуренцию со стороны Яндекса, Контакта, Одноклассников, Гугла и Фейсбука, Мейлру остается на плаву и не теряет своих позиций. Это уже что-то — посмотрите на тот же Рамблер.
В общем, скорее всего, это ошибка, но все возможно :)
Единственное, с чем я не согласен, так это с попыткой заменить JavaScript на что-то другое. В реальной жизни такие идеи не срабатывают, т.к. создатели своих языков не достаточно полно учитывают специфику JS и браузеров. Исключением можно назвать разве что CoffeeScript. Он обходит все скользкие моменты JS и производит вполне дебагоспособный код, проходящий все проверки на «вшивость» — JSLint, es5 strict mode.
Если б я создавал язык для компиляции в JS сегодня, я бы не заморачивался и стал бы компилировать в CoffeeScript, а результат — уже в JS.
Если нам так уж нужно, чтобы элементы находились в определенном порядке, не лучше ли формализовать этот порядок в виде компаратора и использовать SortedSet?
А если порядок не нужен, почему бы не добавлять элементы в конец списка?
А если ожидаемое количество элементов известно, не проще ли создать ArrayList с заданным первоначальным размером?
А если все-таки, несмотря на все вышеперечисленные предложения, больше подходит LinkedList, не стоит ли посмотреть в сторону B-деревьев?
Есть только один сценарий, при котором LinkedList уместен — когда он стоит в основе реализации очереди, используемой несколькими потоками.
Типичная сессия пользователя выглядит так: он открывает браузер, выбирает страницу на SpeedDial, затем приближается, если нужно, ткнув на экран. Читает страницу, скроля ее пальцем. Если ему хочется прокрутить ее быстро вверх или вниз, он использует появляющиеся кнопки. Также он может прыгать между отдельными участками страницы, используя кнопку Назад. Когда сеанс закончен, пользователь нажимает Назад и возвращается в Speed Dial. Потом он также может выбрать следующую страницу, и все пойдет по новой. Открытие нескольких табов идет по долгому нажатию, а переключение между ними также производится через кнопку, соседствующую с кнопкой Назад.
Таким образом, большинство действий, связанных с просмотром вебстраниц, можно выполнять одним пальцем, держась второй рукой за поручень в транспорте, например.
Из своего опыта скажу, что даже в тех случаях, когда он по идее должен был дать прирост в производительности — т.е. большой список с частым удалением и добавлением элементов в середину и начало списка — ArrayList все равно оказывался быстрее.
Объяснение простое: ArrayList внутри себя использует System.arrayCopy — нативную функцию, которая отрабатывает на удивление шустро. В то же время для LinkedList'а приходится переопределять несколько указателей, но это не самое главное. Все эти указатели на предыдущего и следующего обходятся сборщиком мусора. Из-за этого растет время, необходимое для стадии маркинга, а с учетом того, что в одном списке оказываются элементы из разных поколений, вся процедура затягивается еще больше.
В единственный раз, когда LinkedList почти догнал ArrayList по производительности, я решил попробовать PersistentVector из Clojure, и тот оказался в полтора раза быстрее обоих. PersistentVector внутри представляет из себя дерево массивов, поэтому операции вставки приводят к изменению только одного или нескольких сегментов дерева, т.е. одной или нескольким операциям arrayCopy, которая для небольших массивов остается непревзойденной по скорости.
Так что остается ощущение, что LinkedList остается в JDK только для того, чтобы у кандидатов на интервью про его эффективность вопросы задавать.
1. Уязвимости подвержены все версии SSL и TLS 1.0. Только TLS 1.1 и TLS 1.2 остались безопасными. Это означает, что чтобы действительно оставаться в безопасности, нужно в настройках IE или Opera убрать галки для SSL и TLS 1.0 и поставить галки для TLS 1.1 и TLS 1.2. НО: после этого почти весь интернет по HTTPS будет для вас недоступным — я не нашел ни одного крупного сайта, который бы поддерживал последние версии TLS, ни Google, ни Facebook, ни PayPal, ни Microsoft, ни Twitter — никто не поддерживает соединений по этим версиям.
2. Эксплойт работает как Man-in-the-middle в сочетании с внедрением JavaScript-кода на страницу. Злоумышленник слушает https-трафик и вносит на страницу клиента JavaScript. Затем этот скрипт продолжает слать запросы по тому же соединению с известным злоумышленнику содержимым. Зная содержимое тела запроса, злоумышленник может расшифровать HTTP-заголовки, в том числе cookie пользователя.
Это означает, все HTTPS-соединения остаются безопасными, если на странице отключен JavaScript.
Таким образом, у пользователей есть два варианта: либо просто продолжать пользоваться интернетом и надеяться, что их не успеет никто взломать, пока проблему не устранят, либо продолжать пользоваться https, но выключить на защищенных страницах JavaScript. Чего не стоит делать, так это выключать в браузере TLS 1.0, оставляя включенным SSL 3 — так вы делаете себя менее защищенным, т.к. для SSL 3 известны и другие эксплойты, а браузеры оставляют его поддержку включенной только из-за того, что в интернете полно сайтов, которые еще не мигрировали на TLS. При создании соединения браузер пытается использовать самый безопасный протокол, и только потом переключается на более ранние протоколы.
Теперь вопрос, почему никто в интернете не пользуется последними версиями TLS протокола. Ответ: потому что его реализации нет в OpenSSL, которым в свою очередь пользуются все серверы: Apache, Nginx и т.п — и браузеры — Chrome, Safari, Firefox. (см. en.wikipedia.org/wiki/Comparison_of_TLS_Implementations#Protocol_Support) От том, почему ребята из OpenSSL их не реализуют, мне неизвестно. Зато я знаю, что Opera тоже использует OpenSSL (см opera:about), но в ней также есть своя реализация протоколов TLS 1.1 и TLS 1.2 — которые они по всей видимости не могут передать в руки опен-сорс сообщества.