Java Lady, как и трейлеры фильмов — Java4ever и еще какой-то — это все задумка JavaZone — конференции в Осло. Благодаря им популярность JavZone резко подскочила, и из простой региональной конференции они превратились в одно из крупнейших ежегодных событий в мире Java. Туда приезжают лучшие спикеры и участники со всего мира.
Сегодня они замыкают топ-3 конференций: после Devoxx и JavaOne. Oracle после покупки Sun решили сэкономить и объединили JavaOne с Oracle Open World. К сожалению, такая связка работает очень плохо. Конференции совершенно разные по духу. OOW — это форум клиентов и партнеров Оракла, там куча менеджеров, управленцев и сейлов. JavaOne — это событие в первую очередь для инженеров, людей, которые используют язык и технологии в своей работе и делают с помощью Java самые разнообразные вещи. Атмосфера совершенно другая: больше хаккерская и неформальная.
На первой объединенной конференции джависты оказались вторым номером: все кейноуты больше направлены на сейлз, чем на engineering, а сессии и презенцации проходили в залах и помещениях второго эшелона. Затем в тот же год прошел Devoxx и имел ошеломительный успех. Отличные презентации, много новостей мира Java и рекордная посещаемость. С тех пор именно Devoxx — основная конференция джавистов.
Оракл это естественно не устраивает: Devoxx — независимая конференция, не контролируемая Ораклом. Поэтому они хотят вернуть себе утраченное лидерство. Они посмотрели на JavaZone, увидели, что прием с видео работает, и создали этот ролик в преддверии своей JavaOne. Также пригласили кучу звезд — на последней конференции Стинг выступал, если я не ошибаюсь. Ну, и в целом уровень конференции растет, хотя до JavaOne времен Sun им еще далеко.
Сейчас разрбатываем продукт для американского рынка. Будет устанавливаться в интранетах и выйдет в лучшем случае в конце будущего года. Пока что IE8 поддерживаем, хотя тратим на него одного треть ресурсов.
На IE9 нареканий нет — для нас он обгоняет Хром по скорости и с ним одним никогда не было никаких проблем. Приятная метаморфоза! :)
Спасибо! Не знал, что в России такое творится. Так понимаю, взяли один из дистрибутивов Линукса и сделали его автоматически сертифицируемым? Т.е. если админ в каком-то госучреждении захочет перейти на Линукс и предложит именно этот дистр, то ему начальство будет не вправе отказать, т.к. Национальная платформа — с высочайшего одобрения? Тогда в общем-то дело хорошее. 5 млн. жалко, конечно, но могло быть и все 500.
Что такое НПП и СПО? Я так понимаю, что СПО — это Свободное программное обеспечение, хотя в такой вариации термин free/opensource мне не встречался давно.
А НПП? И вообще не понятно, о чем статья. Хоть бы пару-тройку абзацев введения для тех, кто не в курсе.
Я тоже сейчас напишу об расчетах конечных решеток логических выражений с сохранением симметрии, и вы не поймете ничего.
Посмотрите пару-тройку techtalks или лекций зарубежных авторов — всегда-всегда в речи присутствует введение, часто разжеванное так, что и 12-летние дети понять могут, о чем речь. А вы? «Мысли по поводу» — ассоциативный ряд какого-то политолога, ошибшегося сайтом.
Наследование само по себе в языке с dynamic dispatch не нужно, т.к. чтобы добиться полиморфного поведения, достаточно просто гарантировать, что ссответствующий метод есть у объекта. Причем, семантически не важно, лежит ли метод в самом объекте или где-то в цепи предков-прототипов, — в любом случае вызов пройдет — а это именно то, что нам нужно. Поэтому теоретически вполне можно обойтись простым копированием желаемых методов из одного объекта в другой (т.е. использовать миксины). Вопрос лишь в том, как разруливать ситуации, когда копируемый метод уже есть в целевом объекте. Тут два варианта — либо заменять, либо нет. Им соответствуют два метода из Underscore: extend и defaults.
Управлять прототипами может быть удобнее в случае, когда иерархия классов достаточно глубокая: 3 и больше. Для простых же случаев описанной выше функциональности миксинов более чем достаточно.
На своем опыте могу сказать, что вопросам наследования в JavaScript особенно много внимания уделяют начинающие разработчики. При этом основной вопрос, который их мучает, — это как с помощью прототипов реализовать классическое наследование. Особенно это справедливо для тех, кто приходит из статических языков, и потому с концепцией динамической передачи управления не знаком.
С другой стороны, модель миксинов дается таким новичкам гораздо легче, и они начинают с успехом ее применять. Это не значит, что они так и не понимают работу прототипов, но в большинстве случаев знания о том, что метод может быть определен где-то в цепи прототипов, вполне достаточно для комфортной работы с языком.
Прямая столешница с регулируемой высотой — наше все. Из желательного, но совсем необязательного:
— дырка для проводов в задней части стола.
— автоматический подъемник, можно ручной, но на «червяке», чтобы регулировать высоту было не тяжело.
— тумбочка с ящиками, на колесиках — ни в коем случае нельзя делать ящики в столе — они могут здорово мешать во время парных сессий.
Бонус: «гостевой» стул — раздражает, когда приходится ходить к компьютеру коллеги со своим стулом.
Чего в столе не должно быть:
— Всевозможных углов и поворотов. Стол должен быть прямоугольный.
— Полочек и ящичков — только биться об них ногами, руками и головой.
— Этой выезжающей доски для клавиатуры с мышью.
— всевозможных дырок, углублений, различных «зон», различных материалов поверхности и прочей чепухи.
— Колесиков — особенно фееричными бывают столы на колесиках со стульями на колесиках и ездящими полочками с клавиатурой.
Может быть, я еще что-то забыл, но в целом вроде все так. Да, насчет системника: он может быть на столе, рядом со столом, но ни в коем случае не под столом — смотри выше про тумбочку.
Хорошо, вот вам пример из школы: Петя не любил английский и получал по нему плохие оценки много лет до конца десятого класса. Затем он стал играть в игры на компьютере, и язык сам собой начал учиться. В 11м классе Петя получал только 5. По-английски он разговаривает лучше всех, грамматика безупречна и фонетика на высоком уровне. Петя влюбился в язык и собирается поступать на факультет романо-германской филологии. Его учительница прослезилась, когда тот декламировал Шекспира в оригинале. Вы считаете, что Пете надо поставить 5, 4 или 3?
Тут палка о двух концах. Можно брать среднюю оценку за все года и оценку за финальный экзамен, а потом брать среднее. Или брать лучшую. Или не учитывать ничего, кроме экзамена. В любом случае будут недовольные, и любой из этих вариантов вполне валиден.
Именно потому, что и ваш вариант, и текущий порядок — валидны, — я не вижу смысла в изменении.
На самом деле проблема не сколько в них, сколько в том, что throws — часть сигнатуры метода. Checked Exceptions — как вирус — стоит вызвать в своем коде метод, который кидает такие исключения, и нужно решать, что же делать: то ли выбрасывать наверх, добавляя throws к своему методу, то ли добавлять catch-блок.
Первое не всегда возможно: ваш метод может быть частью интерфейса или перекрывать метод предка. Если у предка не было throws, значит, вы не можете добавлять его.
Ловить исключение? А что если у меня нет мыслей относительно того, что с ним делать? Очень много старого API написано таким образом: «ой, я тут делаю что-то, что может не сработать, но теперь, дорогой программист, это уже твоя проблема.» Очень часто (читай, в 99% случаев) в коде обработчика такого исключения выглядит так: обернули exception в RuntimeException и кинули опять. Исключение кидается, но в throws уже не светится.
А смысл тогда в таком обработчике? Вы говорите о документации. А что мешает вам написать throws и перечислить в нем RuntimeExceptions? Java такое разрешает, но компилятор не проверяет рантайм-исключения и не делает их частью сигнатуры. Также, можно просто вписать его в JavaDoc для метода. То же самое вы можете сделать в своем C#.
Поскольку сейчас все считают checked exceptions неудачной идеей, все новые API искользуют rantime exceptions. В то же время, старое API никто из стандартной библиотеки не убирает, и все им продолжают пользоваться.
Вот и получается, что, работаю я, например, с файлами. Сразу получаю простыню из обработчиков исключений: FileNotFoundException, IOException, и т.п. Или, например, JDBC — сулит нам SqlException. В то же время, если я использую JDBC templates из Spring, то иметь дело я буду только с runtime exceptions, и значит, не буду обязан писать код обработки исключений, если, например, не имею представления о том, что делать с той или иной ошибкой на этом уровне кода.
А зачем? Например, в моем ВУЗе была рейтинговая система: нужно было набрать определенные баллы в семестре, чтобы иметь шансы на высший балл в сессии. Я часто получал подобный минимум, а когда преподаватель предлагал освободиться с тройкой, жал плечами и отказывался: все равно я знал, что экзамен на пять сдам. И сдавал.
Вы хотите сказать, что я не имел права на высший балл? А с чего вы взяли? Вы хотите поощрять знания, умения или зубрежку с задротством?
Имхо, любой человек имеет право на ошибку, если он ее исправляет. Я всегда знал, что даже если у меня не все складывается удачно в семестре, я все равно смогу исправить положение. Ваш же вариант приведет к тому, что после одной ошибки у меня пропадет стимул исправлять положение — получил я, например, 0. И знаю, что все — семестр запорот. Зачем мне стараться дальше?
Экзамен должен быть один и должен определять все сразу. Потому что в реальной жизни все работает точно также. Я не буду, например, проводить с вами десять собеседований на работу, чтобы решить — подойдете ли вы мне. Я дам вам один шанс: не получилось — до свидания.
Не могу понять, чем ваше предложение существенно отличается от текущего положения.
1. Разнести территориально: сейчас в большинстве школ начальные классы отделены от остальных. В моей школе это было отдельное крыло. В школе, где преподает моя мама — отдельное здание.
2. Достигается засчет факультативных занятий и заданий повышенной сложности. Имхо, вполне индивидуально.
3. А современные контрольные-экзамены разве не это делают?
4. Сейчас в большинстве ВУЗов есть т.н. подготовительное отделение и курсы. В райцентр, где я рос, приезжали преподаватели ВУЗов и проводили занятия. Штука была очень и очень полезной. Финансировать это из госказны? Можно, но имхо, не обязательно.
Вообще насчет разделения школьников средних и старших возрастов у меня сомнения. Зачем? В любом случае человеку нужно уметь общаться с людьми разных возрастов и характеров. Подобное разделение создаст дополнительные трудности в развитии общения.
GC с refcounting работает также, как shared_ptr — каждый указатель сам следит за своим временем жизни. Также в дополнение используется трейсер для того, чтобы удалять циклы. Но трейсер совсем не обязательно запускать на каждом вызове GC. Так что по времени работа такого коллектора вполне сравнима с работой умных указателей.
Вы, может быть, удивитесь, но в Java тоже иногда пишут сои аллокаторы, чтобы снизить нагрузку на GC: habrahabr.ru/company/odnoklassniki/blog/115881/ Тоже вещь в себе, но иногда полезная. Также и GC в C++ — его даже в стандарт хотели включить, но потом отложили на неопределенный срок.
Ну, не знаю. Излишняя типизация, по-моему, тоже вредна. Производительность в том же Clojure, о котором упоминали выше, достигается за счет проставления небольшого числа аннотаций в коде. Причем подход в этом случае сугубо прагматичный: запускаем профайлер, находим узкие места, расставляем аннотации, повторяем. Обычно одного раза хватает, чтобы по производительности приблизиться к Java -server. Причем, даже не делая этого, мы получаем достаточно солидную скорость.
Насчет пунктов 2 и 3 советую посмотреть презентацию Rich Hickey с StrangeLoop 2011. Там он как раз и говорит о том, что ни типы, ни тесты, не панацея. У всех наших багов есть одно уникальное свойство: они проходят все тесты и не ловятся компилятором. Типизация как защита от ошибок — переоцененное преимущество. На собственном опыте разработки на JavaScript могу сказать, что ошибки типизации возникают только на очень-очень ранних этапах работы с языком и пропадают уже после пяти дней использования.
Наш главный враг, главный источник багов и головной боли для программистов — излишняя сложность логики. Возникает она в основном из-за огромного количества степеней свободы состояния программ. Чем меньше изменяемых значений, чем меньше сущностей, чем менее сложна их структура и взаимодействие друг с другом, тем легче такие системы сопровождать. И типизация тут играет очень малую роль.
Про систему документации могу сказать, что важнее не типы параметров, а их имена. Если из имени ничего не понятно, что-то не так с кодом.
Лучшие IDE всегда были для Smalltalk — языка с динамической типизацией. Там понятия «среда разработки» и «среда выполнения» тождественны. Значит, вы можете в работающей системе заглянуть внутрь, осмотреть граф объектов и изменить фрагменты кода, чтобы исправить ошибку. Ни один современный язык вам не даст такой свободы.
Думать о типах? Я думаю о решении задачи. Типы даже в Java или C# — вторичный продукт.
Вот у меня такой вопрос возник в связи с этими новыми умными указателями. Ведь по сути дела они за вас делают reference counting и при этом за счет разных типов (unique, shared, weak) решают проблему циклов. Оно, конечно, круто — безболезненное управление памятью, и при этом нет никакого сборщика мусора. Но в то же время все эксперты по GC и memory management говорят, что reference counting — это слишком медленно, и сегодня никто с его помощью сборщик мусора не пишет.
А в C++ теперь хотят его использовать. Как же так? Или я чего-то не понимаю?
Хмм, интересная фича, о которой не знал. В Java есть подобное: checked exceptions. Для данного семейства исключений программист должен либо хендлить их внутри метода, либо указывать в сигнатуре, что они бросаются и нне хендлятся. Например, так:
По задумке создателей языка программистам надлежало пользоваться именно checked exceptions, а runtime exceptions оставались за рантаймом, т.е. виртуальной машиной. Однако на деле оказалось, что использовать checked exceptions неудобно — куча танцев с бубном из-за того, что throws является частью сигнатуры метода, а значит, ее приходится учитывать при наследовании или реализации интерфейсов.
В последующем введение таких исключений стали считать ошибкой создателей Java, от них отказываются во всех языках, появившихся после, а в самой Java их использование ограниченно старым API.
Я всегда думал, что Java — единственный язык подобного рода. Оказалось, нет. Молодцы, что убрали это из стандарта.
Сегодня они замыкают топ-3 конференций: после Devoxx и JavaOne. Oracle после покупки Sun решили сэкономить и объединили JavaOne с Oracle Open World. К сожалению, такая связка работает очень плохо. Конференции совершенно разные по духу. OOW — это форум клиентов и партнеров Оракла, там куча менеджеров, управленцев и сейлов. JavaOne — это событие в первую очередь для инженеров, людей, которые используют язык и технологии в своей работе и делают с помощью Java самые разнообразные вещи. Атмосфера совершенно другая: больше хаккерская и неформальная.
На первой объединенной конференции джависты оказались вторым номером: все кейноуты больше направлены на сейлз, чем на engineering, а сессии и презенцации проходили в залах и помещениях второго эшелона. Затем в тот же год прошел Devoxx и имел ошеломительный успех. Отличные презентации, много новостей мира Java и рекордная посещаемость. С тех пор именно Devoxx — основная конференция джавистов.
Оракл это естественно не устраивает: Devoxx — независимая конференция, не контролируемая Ораклом. Поэтому они хотят вернуть себе утраченное лидерство. Они посмотрели на JavaZone, увидели, что прием с видео работает, и создали этот ролик в преддверии своей JavaOne. Также пригласили кучу звезд — на последней конференции Стинг выступал, если я не ошибаюсь. Ну, и в целом уровень конференции растет, хотя до JavaOne времен Sun им еще далеко.
На IE9 нареканий нет — для нас он обгоняет Хром по скорости и с ним одним никогда не было никаких проблем. Приятная метаморфоза! :)
Что такое НПП и СПО? Я так понимаю, что СПО — это Свободное программное обеспечение, хотя в такой вариации термин free/opensource мне не встречался давно.
А НПП? И вообще не понятно, о чем статья. Хоть бы пару-тройку абзацев введения для тех, кто не в курсе.
Я тоже сейчас напишу об расчетах конечных решеток логических выражений с сохранением симметрии, и вы не поймете ничего.
Посмотрите пару-тройку techtalks или лекций зарубежных авторов — всегда-всегда в речи присутствует введение, часто разжеванное так, что и 12-летние дети понять могут, о чем речь. А вы? «Мысли по поводу» — ассоциативный ряд какого-то политолога, ошибшегося сайтом.
Наследование само по себе в языке с dynamic dispatch не нужно, т.к. чтобы добиться полиморфного поведения, достаточно просто гарантировать, что ссответствующий метод есть у объекта. Причем, семантически не важно, лежит ли метод в самом объекте или где-то в цепи предков-прототипов, — в любом случае вызов пройдет — а это именно то, что нам нужно. Поэтому теоретически вполне можно обойтись простым копированием желаемых методов из одного объекта в другой (т.е. использовать миксины). Вопрос лишь в том, как разруливать ситуации, когда копируемый метод уже есть в целевом объекте. Тут два варианта — либо заменять, либо нет. Им соответствуют два метода из Underscore: extend и defaults.
Управлять прототипами может быть удобнее в случае, когда иерархия классов достаточно глубокая: 3 и больше. Для простых же случаев описанной выше функциональности миксинов более чем достаточно.
На своем опыте могу сказать, что вопросам наследования в JavaScript особенно много внимания уделяют начинающие разработчики. При этом основной вопрос, который их мучает, — это как с помощью прототипов реализовать классическое наследование. Особенно это справедливо для тех, кто приходит из статических языков, и потому с концепцией динамической передачи управления не знаком.
С другой стороны, модель миксинов дается таким новичкам гораздо легче, и они начинают с успехом ее применять. Это не значит, что они так и не понимают работу прототипов, но в большинстве случаев знания о том, что метод может быть определен где-то в цепи прототипов, вполне достаточно для комфортной работы с языком.
— дырка для проводов в задней части стола.
— автоматический подъемник, можно ручной, но на «червяке», чтобы регулировать высоту было не тяжело.
— тумбочка с ящиками, на колесиках — ни в коем случае нельзя делать ящики в столе — они могут здорово мешать во время парных сессий.
Бонус: «гостевой» стул — раздражает, когда приходится ходить к компьютеру коллеги со своим стулом.
Чего в столе не должно быть:
— Всевозможных углов и поворотов. Стол должен быть прямоугольный.
— Полочек и ящичков — только биться об них ногами, руками и головой.
— Этой выезжающей доски для клавиатуры с мышью.
— всевозможных дырок, углублений, различных «зон», различных материалов поверхности и прочей чепухи.
— Колесиков — особенно фееричными бывают столы на колесиках со стульями на колесиках и ездящими полочками с клавиатурой.
Может быть, я еще что-то забыл, но в целом вроде все так. Да, насчет системника: он может быть на столе, рядом со столом, но ни в коем случае не под столом — смотри выше про тумбочку.
Тут палка о двух концах. Можно брать среднюю оценку за все года и оценку за финальный экзамен, а потом брать среднее. Или брать лучшую. Или не учитывать ничего, кроме экзамена. В любом случае будут недовольные, и любой из этих вариантов вполне валиден.
Именно потому, что и ваш вариант, и текущий порядок — валидны, — я не вижу смысла в изменении.
Да и вообще — кого волнуют оценки?
На самом деле проблема не сколько в них, сколько в том, что throws — часть сигнатуры метода. Checked Exceptions — как вирус — стоит вызвать в своем коде метод, который кидает такие исключения, и нужно решать, что же делать: то ли выбрасывать наверх, добавляя throws к своему методу, то ли добавлять catch-блок.
Первое не всегда возможно: ваш метод может быть частью интерфейса или перекрывать метод предка. Если у предка не было throws, значит, вы не можете добавлять его.
Ловить исключение? А что если у меня нет мыслей относительно того, что с ним делать? Очень много старого API написано таким образом: «ой, я тут делаю что-то, что может не сработать, но теперь, дорогой программист, это уже твоя проблема.» Очень часто (читай, в 99% случаев) в коде обработчика такого исключения выглядит так: обернули exception в RuntimeException и кинули опять. Исключение кидается, но в throws уже не светится.
А смысл тогда в таком обработчике? Вы говорите о документации. А что мешает вам написать throws и перечислить в нем RuntimeExceptions? Java такое разрешает, но компилятор не проверяет рантайм-исключения и не делает их частью сигнатуры. Также, можно просто вписать его в JavaDoc для метода. То же самое вы можете сделать в своем C#.
Вот и получается, что, работаю я, например, с файлами. Сразу получаю простыню из обработчиков исключений: FileNotFoundException, IOException, и т.п. Или, например, JDBC — сулит нам SqlException. В то же время, если я использую JDBC templates из Spring, то иметь дело я буду только с runtime exceptions, и значит, не буду обязан писать код обработки исключений, если, например, не имею представления о том, что делать с той или иной ошибкой на этом уровне кода.
Вы хотите сказать, что я не имел права на высший балл? А с чего вы взяли? Вы хотите поощрять знания, умения или зубрежку с задротством?
Имхо, любой человек имеет право на ошибку, если он ее исправляет. Я всегда знал, что даже если у меня не все складывается удачно в семестре, я все равно смогу исправить положение. Ваш же вариант приведет к тому, что после одной ошибки у меня пропадет стимул исправлять положение — получил я, например, 0. И знаю, что все — семестр запорот. Зачем мне стараться дальше?
Экзамен должен быть один и должен определять все сразу. Потому что в реальной жизни все работает точно также. Я не буду, например, проводить с вами десять собеседований на работу, чтобы решить — подойдете ли вы мне. Я дам вам один шанс: не получилось — до свидания.
1. Разнести территориально: сейчас в большинстве школ начальные классы отделены от остальных. В моей школе это было отдельное крыло. В школе, где преподает моя мама — отдельное здание.
2. Достигается засчет факультативных занятий и заданий повышенной сложности. Имхо, вполне индивидуально.
3. А современные контрольные-экзамены разве не это делают?
4. Сейчас в большинстве ВУЗов есть т.н. подготовительное отделение и курсы. В райцентр, где я рос, приезжали преподаватели ВУЗов и проводили занятия. Штука была очень и очень полезной. Финансировать это из госказны? Можно, но имхо, не обязательно.
Вообще насчет разделения школьников средних и старших возрастов у меня сомнения. Зачем? В любом случае человеку нужно уметь общаться с людьми разных возрастов и характеров. Подобное разделение создаст дополнительные трудности в развитии общения.
Насчет пунктов 2 и 3 советую посмотреть презентацию Rich Hickey с StrangeLoop 2011. Там он как раз и говорит о том, что ни типы, ни тесты, не панацея. У всех наших багов есть одно уникальное свойство: они проходят все тесты и не ловятся компилятором. Типизация как защита от ошибок — переоцененное преимущество. На собственном опыте разработки на JavaScript могу сказать, что ошибки типизации возникают только на очень-очень ранних этапах работы с языком и пропадают уже после пяти дней использования.
Наш главный враг, главный источник багов и головной боли для программистов — излишняя сложность логики. Возникает она в основном из-за огромного количества степеней свободы состояния программ. Чем меньше изменяемых значений, чем меньше сущностей, чем менее сложна их структура и взаимодействие друг с другом, тем легче такие системы сопровождать. И типизация тут играет очень малую роль.
Про систему документации могу сказать, что важнее не типы параметров, а их имена. Если из имени ничего не понятно, что-то не так с кодом.
Лучшие IDE всегда были для Smalltalk — языка с динамической типизацией. Там понятия «среда разработки» и «среда выполнения» тождественны. Значит, вы можете в работающей системе заглянуть внутрь, осмотреть граф объектов и изменить фрагменты кода, чтобы исправить ошибку. Ни один современный язык вам не даст такой свободы.
Думать о типах? Я думаю о решении задачи. Типы даже в Java или C# — вторичный продукт.
А в C++ теперь хотят его использовать. Как же так? Или я чего-то не понимаю?
beginиend.String[] readLines(String fileName) throws IOExceptionПо задумке создателей языка программистам надлежало пользоваться именно checked exceptions, а runtime exceptions оставались за рантаймом, т.е. виртуальной машиной. Однако на деле оказалось, что использовать checked exceptions неудобно — куча танцев с бубном из-за того, что throws является частью сигнатуры метода, а значит, ее приходится учитывать при наследовании или реализации интерфейсов.
В последующем введение таких исключений стали считать ошибкой создателей Java, от них отказываются во всех языках, появившихся после, а в самой Java их использование ограниченно старым API.
Я всегда думал, что Java — единственный язык подобного рода. Оказалось, нет. Молодцы, что убрали это из стандарта.