Хочешь научиться — устройся Junior'ом в девелоперскую контору. Сениоры по рукам за что-нибудь да по-надоают :) Заодно и уровень подтянется. И поймешь в чем проблемы твои есть. Варись в кругу девелоперов. Поучавствуй в разработке OS проекта. Смени язык на что-нибудь другое.
Я достаточно долгое время писал на РНР и мне казалось, что пишу я сносно. Пока не устроился Junior'ом в девелоперскую контору и не отгреб люлей за некоторые моменты от сениоров. Так что пинки полезны. Очень полезны. Позволяет взглянуть на свою работы под другим углом. Это позволяет начать ссать кипятком чем потом срать кирпичами. Да и вообще, командная работа — это хорошо. Главное не воспринимать критику «в штыки» и быть готовым к ней.
Глядя на свой сегодняшний код я могу сказать: мой код все еще очень далек от идеала, но он на порядки лучше, чем был бы, работай я в одиночку. Так что успехов вам. Ну и Чистый код к прочтению не помешает ;)
Хоть посту и месяц с небольшим, но сегодня я открыл для себя Lombok и он сделал остаток моего дня лучше!
Дописываю проект на Struts2 и понял, на сколько мне надоело в каждом классе писать аннотации писать геттеры/сеттеры — теряется концентрация на идее. А сделать поле публичным религия, что называется, не позволяет.
Вспомнил об этом замечательном проекте именно благодаря этой статье. За что автору «респект и уважуха»! :)
Я говорю, что изменение состояния объекта тогда, когда надо и когда не надо — не есть гуд и ведет к проблемам.
Я пишу сейчас и наверное еще долгое время буду писать на Java. Это не значит, что я не использую ООП, использую только ФП. Все зависит от конкретной ситуации. Голова дана не только, что бы туда есть.
При тупом использовании ФП везде и всюду (если конктрено, то в узких местах) лучше жить не становится, а скорее даже хуже (говорю конкретно про Java/Scala).
Так же как и при тупом использовании ООП там где оно нафиг не нужно.
Автомагически можно получить себе только перформанс проблемы, долгие вечера дебугированя и раннюю потерю волос.
Да. Т.е. у вас есть желание иметь объект, шаренный между разными потоками и смотреть, вылавливать какой поток в какой момент изменит его состояние, что приведет к крешу? Иметь stateful service(тогда когда это нафиг не надо), который время от времени крешится потому что потоки что-то не поделили? Отлавливать dead lock'и на продакшне? У меня такого желания нет. Я видел много разного говна. Большая часть трудноотлавливаемого говна, что я видел была связана с имзеняемым состоянием и многопоточностью. Так что философия в данном вопросе насчет абстракций и изменяемых состояний, на мой взгляд, немного не к месту.
Например конвертацией Java'шных коллекций туда и обратно. Я знаю, про implicit конвертацию из/в java'шные коллекции. Но это тоже больно. Приплюсуем сюда struts2 с желанием итерироваться из JSP с помощью тега <s:iterate /> и получим совсем не клевую ситуацию, где нам приходится или проходить путь:
java collection -> scala collection -> java collection. Или же в каждом конкретном случае смотреть, стоит ли коллекцию конвертировать из Java в Scala или нет.
Помимо того добавим сюда тот факт, что на прямую мы не можем использовать Scala'шный Option и поэтому в POJO нам приходится изворачиваться и писать что-то в роде:
import java.math.{BingInteger => JBigInt}
import java.lang.{Long => JLong}
class Pojo {
<hh user=BeanProperty> var id: JBigInt = _
<hh user=BeanProperty> var name: String = _
<hh user=BeanProperty> var count: JLong = _
}
вместо желаемого
class Pojo {
var id: Option[BigInt] = _
var name: Option[String] = _
var count: Option[Long] = _
}
Вся красота теряется. Желание избежать java'шных костылей приводит к тому что мы подпираем другими костылями код.
Но, к сожалению, я не очень хорошо ориентируюсь в Scala мире. Возможно есть фреймворки, которые либо грамотно оборачивают вышеуказанных монстров (Hibernate) либо же предлагают хорошую альтернативу (я слышал о веб-фреймворках Lift и Play, но, к своему сожалению не успел познакомиться с ними еще, так что не могу прокомментировать).
Scala несет себе много фундаментальных отличий и большое количество улучшений, синтаксического сахара.
Но, к сожалению, в Enterprise системах ее еще несколько больно использовать. В частности из-за еще относительно малого количества стабильных библиотек, которые были написаны специально для Scala. А использовать Scala вместе с Struts2, Spring Jdbc, Hibernate. Это будет намного больнее и уродливее, чем написать это просто на Java.
Многие так называемые паттерны — лишь набор задокументированных ворк-араундов вокруг лимитаций наложенных языком. Так что я бы забил и радовался, если C# позволяет такое писать.
У меня в Java такого нет и, поэтому, я буду дальше продолжать писать абстрактные фабрики. Не потому что это _правильно_, или клево, или мне это нравится, или я получаю удовольствие от усложнения кода, а потому что язык, на котором я пишу каждый день накладывает на меня такие ограничения.
Я хотя и не люблю Майкрософт и их продукты, но по-моему зря его винят в том, что он выпустил мало фич/мало продуктов и т.п. Там такое наследие говнокода, что будь здоров. А доливание индусов на проект скорости и качества разработки не прибавит.
Меня поражает эта статья. Автор, ты хочешь палкой докторской колбасы забить гвозль и удивляешься, че так хреново получается. А я вам скажу: в жопу эту тяжелость и RICH клиенты всегда и всюду. Только вот че-то все в сторону минималзима идут. Наверное просто так. Эволюция не в ту сторону пошла :)
Так что я бы наверное придержался мнения: никуда мигрировать ПОКА ЧТО не нужно. а если вам нужен rich UI с нативными свистелками-перделками, то в зубы фреймворк нативный под платформу и вперед и с песней.
HTML/CSS/JS выполняет свою работу. Когда перестанет справляться появится что-то более мощное, что заменит их. Да и уже сегодня есть туева куча JS фреймворков облегчающая жизнь, да и кое-что по-тяжелее (GWT, Vaadin).
О некоторых фичах на мой взгляд нужно знать, что они есть, но использовать их только тогда, когда это нужно, а не везде и всюду. Так же как Reflection в Java. Я стараюсь обходиться без него столько, сколько можно. По правде мне реально никогда не нужно было его использовать так, что прямо «нужно и по другому никак». Когда натыкаюсь на такой Java код, который использует Reflection и вижу, что без него можно было вполне обойтись, что все было необоснованно усложнено, меня это злит.
Мне довелось видеть код реального проекта, написанного на Scala. Очень много неочевидных вещей. Высокая вероятность выстрелить себе в ногу. Особенно хорошо порой проседает производительность. Так как Scala все равно компилируется в байт код, который потом выполняется JVM, то в этом плане когда пишешь на Java многие вещи намного прозрачнее, чем на Scala.
Некоторые фичи Scala меня действительно пугают. Очень очень сильно. Казалось бы — какая удобная фича — implicit conversions. Но блин, в то же время это такая боль. очень сложно разобраться потом в этом винигрете. Некоторые вещи мне напротив нравятся, такие как immutability. Но опять же, все хорошо в меру.
Больше всего граблей на мой взгляд на стыке Java и Scala. Когда ты используешь либы написанные на Java и пытаешься их использовать в Scala коде. С одной стороны это удобно. С другой стороны это трудноуловимые баги.
Я маловато работал с SpringMVC и REST сервисами. В Strust2 у нас делается так(хотя c XML/REST мы и не работаем):
1). В интерцепторе(на каждый запрос) открывается Hibernate транзакция.
2). Конвертер типов достает hibernate'ом нужную нам сущность по ID.
3). дальше мы внутри контроллера/JSP страницы делаем с этой сущностью что хотим — в том числе итерируемся по lazy коллекциям и т.п.
4). В интерцепторе из пункта 1). коммитим транзакцию после запроса
Я достаточно долгое время писал на РНР и мне казалось, что пишу я сносно. Пока не устроился Junior'ом в девелоперскую контору и не отгреб люлей за некоторые моменты от сениоров. Так что пинки полезны. Очень полезны. Позволяет взглянуть на свою работы под другим углом. Это позволяет начать ссать кипятком чем потом срать кирпичами. Да и вообще, командная работа — это хорошо. Главное не воспринимать критику «в штыки» и быть готовым к ней.
Глядя на свой сегодняшний код я могу сказать: мой код все еще очень далек от идеала, но он на порядки лучше, чем был бы, работай я в одиночку. Так что успехов вам. Ну и Чистый код к прочтению не помешает ;)
Дописываю проект на Struts2 и понял, на сколько мне надоело в каждом классе писать аннотации писать геттеры/сеттеры — теряется концентрация на идее. А сделать поле публичным религия, что называется, не позволяет.
Вспомнил об этом замечательном проекте именно благодаря этой статье. За что автору «респект и уважуха»! :)
Я говорю, что изменение состояния объекта тогда, когда надо и когда не надо — не есть гуд и ведет к проблемам.
Я пишу сейчас и наверное еще долгое время буду писать на Java. Это не значит, что я не использую ООП, использую только ФП. Все зависит от конкретной ситуации. Голова дана не только, что бы туда есть.
При тупом использовании ФП везде и всюду (если конктрено, то в узких местах) лучше жить не становится, а скорее даже хуже (говорю конкретно про Java/Scala).
Так же как и при тупом использовании ООП там где оно нафиг не нужно.
Автомагически можно получить себе только перформанс проблемы, долгие вечера дебугированя и раннюю потерю волос.
java collection -> scala collection -> java collection. Или же в каждом конкретном случае смотреть, стоит ли коллекцию конвертировать из Java в Scala или нет.
Помимо того добавим сюда тот факт, что на прямую мы не можем использовать Scala'шный Option и поэтому в POJO нам приходится изворачиваться и писать что-то в роде:
вместо желаемого
Вся красота теряется. Желание избежать java'шных костылей приводит к тому что мы подпираем другими костылями код.
Но, к сожалению, я не очень хорошо ориентируюсь в Scala мире. Возможно есть фреймворки, которые либо грамотно оборачивают вышеуказанных монстров (Hibernate) либо же предлагают хорошую альтернативу (я слышал о веб-фреймворках Lift и Play, но, к своему сожалению не успел познакомиться с ними еще, так что не могу прокомментировать).
Но, к сожалению, в Enterprise системах ее еще несколько больно использовать. В частности из-за еще относительно малого количества стабильных библиотек, которые были написаны специально для Scala. А использовать Scala вместе с Struts2, Spring Jdbc, Hibernate. Это будет намного больнее и уродливее, чем написать это просто на Java.
У меня в Java такого нет и, поэтому, я буду дальше продолжать писать абстрактные фабрики. Не потому что это _правильно_, или клево, или мне это нравится, или я получаю удовольствие от усложнения кода, а потому что язык, на котором я пишу каждый день накладывает на меня такие ограничения.
Но полностью избежать изменяемого состояния нельзя, но я стараюсь на сколько это возможно редуцировать изменяемое состояние.
Встречайте:
* Debug Driven Development.
* Brain Fuck Driven Development
Так что я бы наверное придержался мнения: никуда мигрировать ПОКА ЧТО не нужно. а если вам нужен rich UI с нативными свистелками-перделками, то в зубы фреймворк нативный под платформу и вперед и с песней.
HTML/CSS/JS выполняет свою работу. Когда перестанет справляться появится что-то более мощное, что заменит их. Да и уже сегодня есть туева куча JS фреймворков облегчающая жизнь, да и кое-что по-тяжелее (GWT, Vaadin).
Некоторые фичи Scala меня действительно пугают. Очень очень сильно. Казалось бы — какая удобная фича — implicit conversions. Но блин, в то же время это такая боль. очень сложно разобраться потом в этом винигрете. Некоторые вещи мне напротив нравятся, такие как immutability. Но опять же, все хорошо в меру.
Больше всего граблей на мой взгляд на стыке Java и Scala. Когда ты используешь либы написанные на Java и пытаешься их использовать в Scala коде. С одной стороны это удобно. С другой стороны это трудноуловимые баги.
1). В интерцепторе(на каждый запрос) открывается Hibernate транзакция.
2). Конвертер типов достает hibernate'ом нужную нам сущность по ID.
3). дальше мы внутри контроллера/JSP страницы делаем с этой сущностью что хотим — в том числе итерируемся по lazy коллекциям и т.п.
4). В интерцепторе из пункта 1). коммитим транзакцию после запроса
Такую параллель нельзя провести на Spring?