Позволю себе не согласиться с Вами: обладатель заветного места на дне все-таки в чем-то круче и заслуживает это место полностью. Все-таки занять это место с 1(!) выстрела — это невероятное мастерство. Очень хорошо, что он не стал портить красоту и совершенство аккаунта, оставляя комментарии.
Взаимоисключающие параграфа, беспочвенные аналогии, отсылы к домыслам читателя ("… пока не вникаешь в детали") и «общеизвестно», заявления в духе «это плохо, а все кто не согласен не имеют вкуса», отсечение тех, кто будет аргументировано вам возражать по качеству кода подниманием уровня неадекватности до такого, что им просто не захочется пачкаться, обвинение оппонентов в троллинге («Гони всякую пургу на винду»). Даже не верится что все это без учебника по троллингу под рукой.
На мой взгляд есть только один недостаток: Вы не достаточно сил уделили подведению оппонентов к охаиванию винды. Да, неявное утверждение о том, что все проблемы винды в прошлом является весьма мастерским ходом, особенно в совокупности со столь же неявным утверждением о том, что линукс ухудшается со временем, но требует более отзывчивой публики.
Я одного не пойму — зачем именно хабр? Есть площадки без ограничения на частоту постов для троллей и с гораздо более отзывчивой публикой.
Опус про низкоквалифицированного линуксового админа у которого «работающая годами ось» и высококвалифицированного виндового «у которого постоянно что-то падает» — это же шедевр!
Утверждение про убогость интерфейса особенно в контексте сравнения с семеркой — мастерское использование холиварной темы, основанной на вкусе, привычках и домыслах.
Явное оскорбление разработчиков софта, которое сами эти разработчики проигнорируют как не заслуживающее внимания, но возмутятся пользователи — весьма тонкий прием, замаскированный под банальную грубость и невежество.
Назвать всех пользователей нищебродами и фанатиками («культ») (в контексте сравнения интерфейсов сюда попали и пользователи десктопного линукса) — вы были близки к тому, чтобы я поверил в Вашу искренность.
А уж финальный полунамек на какие-то неведомые «детали» — высший пилотаж!
На таких, как вы молиться надо!
Познакомился с ситуацией с обеих сторон, общаясь с HR и несколькими старшекурсниками/выпускниками.
Хоть и Питер, но с точки зрения HR адекватных программистов на начальные должности найти невозможно.
Ребята же просто стесняются, недооценивают себя. Они бы пошли на вакансию программиста-стажера хоть с какой-нибудь зарплатой, лишь бы опыта набрать, но нет таких вакансий.
В итоге есть вакансии, есть люди, но они в параллельных вселенных.
Мало того, что сам редактор неудобный, так еще и поведение довольно неожиданное. Сравните, например, вот этот код запущеный как скрипт и выполненый из-под интерактивной среды:
import scala.actors.Actor.{actor,self,receive}
var caller = self
actor { caller! «Hi!» }
receive { case s => println(s) }
Для тех, кому лень: скрипт выведет Hi! и завершится, а REPL «повиснит» на receive.
Я понимаю, что это вполне объяснимое поведение, но весьма неудобное.
Правда какое-то время назад в подкасте, на который ссылаются выше (http://habrahabr.ru/blogs/java/138184/#comment_4608679), разработчик говорил, что страничка временно не работает под Mac OS.
Спасибо за ссылку! Первый раз подкаст воспринимается настолько интересно (деже не смотря на отваливающихся собеседников и «мне тут ssd принесли»).
Жаль даже там нет ответа почему не scala, хоть его и пытались добиться.
Неужели временные(!) глюки fsc и, я уверен, временная неспособность scala плагина осуществить полноценную поддержку scala — это действительно достойные причины для создания нового языка?
И спамят зачастую не зря если в письме есть одноразовая ссылка на вход без пароля и ссылка чтобы отписаться от рассылки. А складирование всех писем с этого адреса в папочку для емуподобных настроить быстрее даже. чем отписаться.
Музыка, отключающаяся при неактивности страницы! Я вас обожаю! Почему большинство так не делает?
Жаль третья коробка доступна только в винде. Под рукой телефон с полной версией, но все равно жаль.
Спасибо за великолепную игру!
Просто не люблю дезинформировать. Это всегда заканчивается неловкими ситуациями.
Плюс небольшая паранойя: рассылку по компаниям с приглашением сотрудников на конференцию или рекламой чего-нибудь со ссылкой на участие сотрудника на конференции некоторые вполне могут устроить.
Для чего-то им название компании нужно. Как минимум я испорчу им статистику, как максимум — почувствую себя неловко, произнося «не обращайте внимания — это просто я сходил на конференцию, не имеющую отношения к фирме, и зачем-то указал название фирмы».
Решил посмотреть ролики. Жалею о потерянном времени. Занимательный на первый взгляд материал оказался маркетинговой пустышкой.
От простого передергивания и ложных аналогий до откровенной дезинформации.
Начнем с ложной аналогии про телевизор, к которому схема не нужна так как ковыряться паяльником в нем ни кто не будет.
Эта аналогия ложна по целому ряду причин среди которых и важность поломки, и невозможность ждать ремонта, и невозможность легко заменить и необходимость постоянных изменений под изменяющиеся бизнеспроцессы. Но есть и верные аспекты: схема к телевизору нужна телемастеру, который будет его чинить. И если не устроит телемастер от производителя, то сторонний сделает дешевле.
В конце концов исходники нужны не только для изменений, но и для аудита безопасности системы. Даже если их запрещено менять их показывают, чтобы заказчик мог их проверить.
«Приоткрытые исходные коды» — это разделение системы на ядро и бизнеслогику (ядро закрыто, бизнеслогика открыта, возможно без права изменений). Подобное разделение позволяет создавать огромное количество конфигураций с одном ядром. Ядро удается отладить до состояния близкого к идеалу, а бизнеслогику сделать предельно гибкой. Если такого разделения нет, то это огромный минус системы — у 10 заказчиков будут стоять не 10 конфигураций одной системы, а 10 разных систем. И править одни и те же баги ядра придется в 10 системах, что сказывается на стоимости.
Если у вас нет обособленного ядра, то не удивительно, что вы не открываете коды бизнеслогики — вы их просто не можете открыть, не открыв все. Вы можете свой недостаток выдавать за достоинство на презентациях, но зачем это пытаться делать на сайте, где множество людей знают эту тему на практике?
Про отсутствие поддержки со стороны производителя тоже глупость. Опус про недоступность обновлений после самостоятельных изменений я специально дал послушать человеку, который является штатным 1С разработчиком в крупной фирме. Наградой мне было крайне удивленное выражение лица. Для обновления 1С в крупном предприятии требуется 2 часа работы одного программиста. Естественно все изменения делались с оглядкой на то, что их придется поддерживать, но так и должно быть в нормальном IT отделе.
Вообще довольно странно было бы для правки в отчете которую штатный программист в 1С может внести за час, а бухгалтерии она нужна вчера ждать 16 часов и это только на консультацию (кажется такие цифры у вас на сайте).
Про коллапс продукта через полгода самостоятельной разработки тоже жуткое передергивание. Разработчики вашей фирмы не боги, собственные разработчики заказчика тоже не обязательно из дурдома набраны. Хочет заказчик сам поддерживать систему — пусть сколачивает себе хороший IT отдел с соответствующими зарплатами. Банки, например, в свой IT отдел любят разработчиков ДБО переманивать.
Про отсутствие пути назад после самостоятельных изменений — все зависит от ваших возможностей и денег заказчика. Я участвовал в успешном принятии на поддержку функционала наработанного за полтора года крайне низко квалифицированными разработчиками. Долго, дорого, но возможно. Если вы такого не делаете — это исключительно ваш минус.
Всё. 3 минуты от первого ролика. Текст я бы еще осилил, но медленная речь в которой каждое предложение вызывает негодование просто невыносима.
Дальше шли куски про то, что единственный (это почему?) внутренний разработчик уволится и можно ползти на кладбище. Вот только опять же 1С разработчик, которому я все это показывал, оказалось несколько лет назад сам принимал чужие многолетние наработки и фирма пока цела.
А вот что делать, если вы разоритесь или цены за техподдержку увеличите до неприличия? В 1С, САП и других можно просто сменить сопровождающую систему фирму или перейти на собственное сопровождение, а ваши клиенты в западне.
Из формы регистрации можно сделать вывод, что частное лицо туда зарегистрироваться не может — только представитель определенной организации.
Это довольно неудобно для тех, кому Java требуется не для текущего места работы.
Похоже тут смешаны 2 разных спора:
1) Открытый/закрытый код базовой системы.
2) Сторонний/внутренний внедренец и сопровождение.
Заголовок обещает нам рассмотрение первого вопроса, но, почему-то, в тексте рассматривается второй.
Первый вопрос должен решать не заказчик, а внедренец и сопровождение (чаще всего это одно лицо). Для заказчика важным может являться только возможность смены сопровождения.
Были бы на российском рынке внедренцы Open Source ERP, было бы из чего выбирать. Если выбор внедренца сделан в пользу внутреннего (IT отдел), то уже этому внутреннему внедренцу выбирать базу на которой строить ERP.
Второй же вопрос гораздо более сложный, чем хочет его представить автор.
В любом случае фирма будет зависима от внедренца и сопровождающего. Сторонняя фирма может содержать лучших специалистов, гибче выделять ресурсы, иметь несравнимо больший опыт. Свой же IT отдел дешевле, гибче управляется, не старается диктовать как надо работать фирме, а реализовывает именно то, что от него требуется. От своего IT отдела можно добиться работоспособного продукта. Если же удалось добиться качественного продукта, то можно выносить IT отдел в дочернюю фирму и оказывать услуги другим (то есть теоретически возможно, но очень сложно).
У меня маленький опыт работы с ERP, но гораздо больший — работы с ДБО (разработка и внедрение). Приходилось видеть и негативные и позитивные результаты всех подходов: и отвратительные доработки своим IT отделом, и застопорившиеся внедрения сторонней фирмой (крупной, с большим штатом разработчиков), и великолепные самописки, и отлично работающие внедренные системы.
Выбор внедренца и сопровождающего — слишком сложный и многогранный вопрос, чтобы на него можно было дать однозначный ответ. И ответ именно на этот вопрос в большей степени определяет успешность проекта, а не открытость/закрытость кода ядра системы.
Тогда на него не обратили внимания.
Вас бы в палату мер и весов как эталон тролля.
Взаимоисключающие параграфа, беспочвенные аналогии, отсылы к домыслам читателя ("… пока не вникаешь в детали") и «общеизвестно», заявления в духе «это плохо, а все кто не согласен не имеют вкуса», отсечение тех, кто будет аргументировано вам возражать по качеству кода подниманием уровня неадекватности до такого, что им просто не захочется пачкаться, обвинение оппонентов в троллинге («Гони всякую пургу на винду»). Даже не верится что все это без учебника по троллингу под рукой.
На мой взгляд есть только один недостаток: Вы не достаточно сил уделили подведению оппонентов к охаиванию винды. Да, неявное утверждение о том, что все проблемы винды в прошлом является весьма мастерским ходом, особенно в совокупности со столь же неявным утверждением о том, что линукс ухудшается со временем, но требует более отзывчивой публики.
Я одного не пойму — зачем именно хабр? Есть площадки без ограничения на частоту постов для троллей и с гораздо более отзывчивой публикой.
Опус про низкоквалифицированного линуксового админа у которого «работающая годами ось» и высококвалифицированного виндового «у которого постоянно что-то падает» — это же шедевр!
Утверждение про убогость интерфейса особенно в контексте сравнения с семеркой — мастерское использование холиварной темы, основанной на вкусе, привычках и домыслах.
Явное оскорбление разработчиков софта, которое сами эти разработчики проигнорируют как не заслуживающее внимания, но возмутятся пользователи — весьма тонкий прием, замаскированный под банальную грубость и невежество.
Назвать всех пользователей нищебродами и фанатиками («культ») (в контексте сравнения интерфейсов сюда попали и пользователи десктопного линукса) — вы были близки к тому, чтобы я поверил в Вашу искренность.
А уж финальный полунамек на какие-то неведомые «детали» — высший пилотаж!
Познакомился с ситуацией с обеих сторон, общаясь с HR и несколькими старшекурсниками/выпускниками.
Хоть и Питер, но с точки зрения HR адекватных программистов на начальные должности найти невозможно.
Ребята же просто стесняются, недооценивают себя. Они бы пошли на вакансию программиста-стажера хоть с какой-нибудь зарплатой, лишь бы опыта набрать, но нет таких вакансий.
В итоге есть вакансии, есть люди, но они в параллельных вселенных.
def identity[A](x: A): A = x
def implicitly[T](implicit e: T) = e
@inline def locally[T](x: T): T = x
Это не бесполезный код. Это функции импортируемые по умолчанию в любой исходник на scala.
lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_9_1_final/src//library/scala/Predef.scala
Мало того, что сам редактор неудобный, так еще и поведение довольно неожиданное. Сравните, например, вот этот код запущеный как скрипт и выполненый из-под интерактивной среды:
import scala.actors.Actor.{actor,self,receive}
var caller = self
actor { caller! «Hi!» }
receive { case s => println(s) }
Для тех, кому лень: скрипт выведет Hi! и завершится, а REPL «повиснит» на receive.
Я понимаю, что это вполне объяснимое поведение, но весьма неудобное.
confluence.jetbrains.net/display/Kotlin/Welcome
Есть ли он сейчас — не проверял.
kotlin-demo.jetbrains.com/
Правда какое-то время назад в подкасте, на который ссылаются выше (http://habrahabr.ru/blogs/java/138184/#comment_4608679), разработчик говорил, что страничка временно не работает под Mac OS.
Жаль даже там нет ответа почему не scala, хоть его и пытались добиться.
Неужели временные(!) глюки fsc и, я уверен, временная неспособность scala плагина осуществить полноценную поддержку scala — это действительно достойные причины для создания нового языка?
По поводу «Исправляем так»: явное указание implicit функции все-таки моветон. Ошибка исправляется как-то по другому.
Жаль третья коробка доступна только в винде. Под рукой телефон с полной версией, но все равно жаль.
Спасибо за великолепную игру!
Плюс небольшая паранойя: рассылку по компаниям с приглашением сотрудников на конференцию или рекламой чего-нибудь со ссылкой на участие сотрудника на конференции некоторые вполне могут устроить.
Для чего-то им название компании нужно. Как минимум я испорчу им статистику, как максимум — почувствую себя неловко, произнося «не обращайте внимания — это просто я сходил на конференцию, не имеющую отношения к фирме, и зачем-то указал название фирмы».
От простого передергивания и ложных аналогий до откровенной дезинформации.
Начнем с ложной аналогии про телевизор, к которому схема не нужна так как ковыряться паяльником в нем ни кто не будет.
Эта аналогия ложна по целому ряду причин среди которых и важность поломки, и невозможность ждать ремонта, и невозможность легко заменить и необходимость постоянных изменений под изменяющиеся бизнеспроцессы. Но есть и верные аспекты: схема к телевизору нужна телемастеру, который будет его чинить. И если не устроит телемастер от производителя, то сторонний сделает дешевле.
В конце концов исходники нужны не только для изменений, но и для аудита безопасности системы. Даже если их запрещено менять их показывают, чтобы заказчик мог их проверить.
«Приоткрытые исходные коды» — это разделение системы на ядро и бизнеслогику (ядро закрыто, бизнеслогика открыта, возможно без права изменений). Подобное разделение позволяет создавать огромное количество конфигураций с одном ядром. Ядро удается отладить до состояния близкого к идеалу, а бизнеслогику сделать предельно гибкой. Если такого разделения нет, то это огромный минус системы — у 10 заказчиков будут стоять не 10 конфигураций одной системы, а 10 разных систем. И править одни и те же баги ядра придется в 10 системах, что сказывается на стоимости.
Если у вас нет обособленного ядра, то не удивительно, что вы не открываете коды бизнеслогики — вы их просто не можете открыть, не открыв все. Вы можете свой недостаток выдавать за достоинство на презентациях, но зачем это пытаться делать на сайте, где множество людей знают эту тему на практике?
Про отсутствие поддержки со стороны производителя тоже глупость. Опус про недоступность обновлений после самостоятельных изменений я специально дал послушать человеку, который является штатным 1С разработчиком в крупной фирме. Наградой мне было крайне удивленное выражение лица. Для обновления 1С в крупном предприятии требуется 2 часа работы одного программиста. Естественно все изменения делались с оглядкой на то, что их придется поддерживать, но так и должно быть в нормальном IT отделе.
Вообще довольно странно было бы для правки в отчете которую штатный программист в 1С может внести за час, а бухгалтерии она нужна вчера ждать 16 часов и это только на консультацию (кажется такие цифры у вас на сайте).
Про коллапс продукта через полгода самостоятельной разработки тоже жуткое передергивание. Разработчики вашей фирмы не боги, собственные разработчики заказчика тоже не обязательно из дурдома набраны. Хочет заказчик сам поддерживать систему — пусть сколачивает себе хороший IT отдел с соответствующими зарплатами. Банки, например, в свой IT отдел любят разработчиков ДБО переманивать.
Про отсутствие пути назад после самостоятельных изменений — все зависит от ваших возможностей и денег заказчика. Я участвовал в успешном принятии на поддержку функционала наработанного за полтора года крайне низко квалифицированными разработчиками. Долго, дорого, но возможно. Если вы такого не делаете — это исключительно ваш минус.
Всё. 3 минуты от первого ролика. Текст я бы еще осилил, но медленная речь в которой каждое предложение вызывает негодование просто невыносима.
Дальше шли куски про то, что единственный (это почему?) внутренний разработчик уволится и можно ползти на кладбище. Вот только опять же 1С разработчик, которому я все это показывал, оказалось несколько лет назад сам принимал чужие многолетние наработки и фирма пока цела.
А вот что делать, если вы разоритесь или цены за техподдержку увеличите до неприличия? В 1С, САП и других можно просто сменить сопровождающую систему фирму или перейти на собственное сопровождение, а ваши клиенты в западне.
Это довольно неудобно для тех, кому Java требуется не для текущего места работы.
1) Открытый/закрытый код базовой системы.
2) Сторонний/внутренний внедренец и сопровождение.
Заголовок обещает нам рассмотрение первого вопроса, но, почему-то, в тексте рассматривается второй.
Первый вопрос должен решать не заказчик, а внедренец и сопровождение (чаще всего это одно лицо). Для заказчика важным может являться только возможность смены сопровождения.
Были бы на российском рынке внедренцы Open Source ERP, было бы из чего выбирать. Если выбор внедренца сделан в пользу внутреннего (IT отдел), то уже этому внутреннему внедренцу выбирать базу на которой строить ERP.
Второй же вопрос гораздо более сложный, чем хочет его представить автор.
В любом случае фирма будет зависима от внедренца и сопровождающего. Сторонняя фирма может содержать лучших специалистов, гибче выделять ресурсы, иметь несравнимо больший опыт. Свой же IT отдел дешевле, гибче управляется, не старается диктовать как надо работать фирме, а реализовывает именно то, что от него требуется. От своего IT отдела можно добиться работоспособного продукта. Если же удалось добиться качественного продукта, то можно выносить IT отдел в дочернюю фирму и оказывать услуги другим (то есть теоретически возможно, но очень сложно).
У меня маленький опыт работы с ERP, но гораздо больший — работы с ДБО (разработка и внедрение). Приходилось видеть и негативные и позитивные результаты всех подходов: и отвратительные доработки своим IT отделом, и застопорившиеся внедрения сторонней фирмой (крупной, с большим штатом разработчиков), и великолепные самописки, и отлично работающие внедренные системы.
Выбор внедренца и сопровождающего — слишком сложный и многогранный вопрос, чтобы на него можно было дать однозначный ответ. И ответ именно на этот вопрос в большей степени определяет успешность проекта, а не открытость/закрытость кода ядра системы.