Первые 4 пункта — руководство для начинающего драгдилера ;)
9. Издавайте и продавайте дидактические материалы о том как стать успешным. Тем самым Вы формируете легенду о себе и своей успешности. ;)
Очень модно учиться успехам бизнеса у американских ребят. Но я не знаю в какой мере описанное будет применимо в среде с другой культурой и менталитетом.
Я написал несколько игр с испанской колодой. При правильном шаблонизировании описание новой игры достаточно простое, даже изменения в GUI минимальны. Также программировал покер, несколько вариантов шашек, и очень много занимался шахматами. На мой взгляд, лучший способ — это разделить логику правил и геймплей. Например, логика покера — это поиск комбинаций и операции с банком. Логику можно описывать на любом языке, хоть на хаскеле, хоть на джаваскрипте. Геймплей — это общий граф состояний игры, описывающий передачу хода между пользователями, завершение раунда, завершения игры, промежуточные состояния, etc, и обычно сильно связанный с визуализацией в GUI. Описывать его лучше через конечный автомат — в декларативной форме на порядок усложнится отладка.
AI-это отдельная тема. Любой AI состоит из функции генерации ходов и оценочной функции. Генерация ходов не представляет собой проблемы, если описан конечный автомат. А вот оценка позиции и хода представляет собой отдельную задачу, которая не имеет ничего общего с описательной частью игры. Она программируется совершенно отдельно, напр. минимаксным алгоритмом. Более того, во многих случаях для AI приходится генерировать отдельно упрощенный граф состояний (для которого не важны промежуточные состояния GUI), а иногда использовать и другую и модель данных.
Уже давно пишу игры (www.buho21.com). Разработал более-менее универсальную платформу с плагинной архитектурой, позволяющую интегрировать игры. Предложенная идея в основном правильная, хотя и не нуждается в отдельном скриптовом языке. При помощи обычного языка программирования (в моем случае Java), правильно организованного API и ООП можно достичь желаемого результата.
С точки зрения реализации игры всегда будут три компонента: GUI, модель и контроллер. Модель полностью описывает текущее состояние игры. Контроллер принимает действие пользователя, проверяет валидность, и меняет состояние игры. GUI соответственно отображает состояние и визуализирует ходы. Модель хорошо масштабируется для сети: каждый клиент всегда хранит копию текущего состояния игры, ходы передаются всем игрокам партии, контроллер каждого клиента одинаковым образом актуализирует у себя состояние игры.
Проблема начинается, когда модель игры плохо состыковывается с моделью GUI. Например, в шахматах состояние доски логично хранить ввиде матрицы клеток, где фигуры — значения в клетках. GUI использует обратную модель: обычно список визуальных компонентов фигур, которые хранят внутри свои координаты на доске. Необходимо писать достаточно нетривиальный код, связывающий эти две модели. Хороший способ избежать этого — сразу использовать модель, схожую с GUI. Например для карточных игр универсальная модель — это хранить список из всех карт колоды, с указанием, где она находится в данный момент (в колоде, на руках у пользователя, в «бите», на столе в такой то позиции, etc). Для визуализации хода достаточно лишь вычислить координаты позиции для карты и анимировать соответствующий компонент.
Скелет для контроллера настольных игр достаточно прост в первом приближении. Лучший способ описания контроллера и всей логики игры — конечный автомат (finite state machine). Есть куча библиотек на этот счет, я разработал свою. Но потом оказывается, то GUI для визуального отображения ходов (обычно с анимацией) необходима расширенная информация от контроллера о последнем изменении состояния. Например в случае шахмат — это не просто действие пользователя (какая фигура куда сходила), а был ли ход шахом, рокировкой, съеданием. Поэтому частично логику GUI контроллер частично управляет логикой GUI посредством генерации событий после изменения состояния. В других играх ход игрока может генерировать целый каскад событий. Например в игре в покер ситуация, где игрок пошел all-in (одно единственное событие игрока), открываются карты обоих игроков, затем последовательно все карты флопа, затем производится сравнение комбинаций, затем распределяется выигрыш и после этого дилится новый кон.
В следующем приближении обнаружится, что для многих игр, особенно карточных, состояние игры не одинаково для всех игроков — каждый игрок должен видеть только свои карты и карты на столе. И требуется один особый «серверный» контроллер, которому доступно состояние всех карт (если держать полное состояние на клиенте — моментально сломают). Модель игры становится асимметричной, появляются исключительно «серверные» ходы: сдать карту, бросить кубик, etc. Логика должна уметь синхронизировать состояние серверой модели с состояниеми моделей игроков.
По мере написания игр всплывает еще куча дополнительных нюансов. Обнаруживается, что многие игры помимо основного геймплея имеют раунды и таблицу очков, и хотелось бы иметь некий общий шаблон для этого. В онлайн играх очень актуально решить что делать, если пользователь отконнектился: завершить игру, продолжать играть за него машине, продолжить игру с меньшим числом игроков, etc. Также неплохо внедрить логику таймаута на ход: например делать машиной случайный ход. Для этого контроллер должен уметь гененировать всевозможные ходы для данной позиции (которые также можно использовать для валидации хода пользователя). И еще куча нюансов.
Вобщем, что я хотел сказать. Задача написания универсального движка для игр не сводится к созданию языка для описания игровой логики, а к созданию иерархии шаблонов общим функционалом. И написаны они могут быть написаны на любом языке. Для этого нужно проанализировать большое количество игр, разбить на классы (карточные, досочные, настольные). Для каждого из компонентов (GUI, контроллер и модель) выделить абстрактный функционал и написать расширяемые шаблоны. Тем не менее, для любой игры 80% времени всегда будет занимать создание GUI.
> американский программист это 50% инженер, 25% бизнесмен, остальное первооткрыватель, политик, колонизатор и философ
Ух ты! Этакий Капитан Америка прямо!
Практика показывает, что западный программист — это:
— хреновый инженер, т.к. программирование для него — это инструмент зарабатывания денег и не лежит в области его непосредственных интересов. Либо его знания слишком поверхностны, либо слишком узкоспециализированы. Зачем мне знать сверх того, что я могу продать?
— посредственный бизнесмен. Да, в штатах с детства учат подавать и продавать себя, но точно также мало кто на это ведется. Прежде чем посредственному бизнесмену позволят стать успешным, он должен будет доказать свою лояльность, лизать задницы начальства и рвать свою. И то не факт, что что-то перепадет.
— прямолинейный и твердолобый политик. Все его намерения и притязания ясны с первых же минут общения, и не отличаются особой изощренностью. Хочет денег и продвижения.
— совершенно никакой философ. Зациклен на карьере и собственной выгоде. Полет мысли ограничен исключительно земными благами.
Русский инженер — это филосов и исследователь. Западный инженер — это ремесленник.
P.S. А если серьезно, то очередное идеализирование устоявшихся стереотипов.
P.P.S. >А в США ушлые мамочки пихают своих детишек в программисты.
Юриспруденция, менеджмент, медицина.
> 24 Продавайте выгоду, а не функционал
Чистейший американизм. Две вещи, которые я ненавижу: отсутствие внятного описания продукта и отсутствие цены. Страницы пестрят совершенно бесполезными заверениями вроде «наш продукт — вазелин для вашего бизнеса» (не понимаю, неужели люди до сих пор на это покупаются?) При этом информацию о реальном функционале продукта найти бывает очень сложно, а иногда вообще невозможно. Дается лишь общее описание в стиле «универсальный решатель бизнес проблем для тех, кто идет в ногу со временем», без каких-либо деталей. Для клиент становится невозможно оценить чем ваш продукт лучше конкурентов. При таком подходе можно Ладу продать по цене БМВ (что собственно часто и бывает в мире IT) — задачи схожие, описания нет, сравнивать нечего.
Поэтому не надо держать клиента за идиота. Скажи конкретно, что ты продаешь и сколько это стоит, а он уже решит надо это ему или нет, как он это будет использовать и сколько сможет сэкономить.
> 51 Ценовые иллюзии вместо обычных цен
Тоже американизм. Тут либо тебя держат за идиота, неумеющего производить элементарные математические действия, либо ты не идиот, и понимаешь, что таким нехитрым способом тобой пытаются манипулировать, но все-равно с этим соглашаешься. Не знаю как американцам, мне такое портит впечатление.
Не знаю насколько оправдано использование Spring Boot. Для реального проекта не принципиально, потрачу ли я десять минут на подключение зависимостей и написание конфигурации. Также не могу понять полезность spring-boot:run если всю жизнь можно было пускать embedded Jetty container из main(). В большом проекте с кучей профайлов и зависимостей сведется на нет все преимущества автоконфигурирования.
Нужно добавить в начало и конец статьи этап «Зачатие».
Группа инженеров, работая в дряхлой компании, загорается новой идеей, делает прототип и презентует начальству. Начальство настроено скептически: «это не наш профиль», «тут нет денег», «бизнес-модель не отработана», «молодцы, ребята! так держать!», etc… Разочаровавшись, инженеры открывают свою компанию, на коленках в свободное время делают пробную версию, увольняются из корпорации, и пытаются раскрутить продукт. Контакты с клиентами отстались, а гибкость позволяет быстро выйти на самоокупаемость.
Помню партии Крамника против Deep Fritz. Оказывается, по-правилам экземпляр программы предоставлялся гроссмейстеру за полгода для изучения. Поторчав с программой, Крамник находит выигрышную комбинацию, практически всегда с проходными пешками — компьютер их плохо видит, и демонстрирует потом решение на чемпионате. Достаточно всего одной-двух выигрышных партий, остальные сливаются в ничью.
Более того, все программы снабжены базами финалов, до 6-й или 7-й фигуры. Во всех подобных чемпионатах, игра заканчивается, если партия входит в финал, и компьютер показывает результат. Однако результат верен, если человек не ошибется в финале, что даже для гроссмейстеров далеко не всегда верно.
Круто! А сериализация объектов как сделана, если нет информации о полях? В GWT нужно было писать свой генератор, который вызывается на этапе компиляции и делает сериализатор для класса.
Обертки можно генерировать автоматически из W3C IDL. По-моему так TypeScript по-началу делал.
Оч. интересный проект. Сам давно пишу на GWT, писал даже к нему библиотеку для сериализации: code.google.com/p/gwt-streamer/ Не в восторге от платформы.
Интересует несколько вещей:
1. За счет чего все-таки достигается производительность? Разработчики GWT божились, что из .class нельзя получить эффективный JS, что и доказывают проекты вроде Eclipse Java2Script?
2. Насколько я понял, проект должен включать в себя какой-нибудь API для работы с платформой браузера: DOM, Canvas, etc...?
3. Есть какие-нибудь средства для включения нативного JS-кода, как например JSNI?
4. Можно ли расширять или дополнять возможности поддерживаемого API Java не суясь в TeaVM? Что-то вроде GWT super-package?
5. Поскольку в GWT отсутствует рефлексия, все объявления статические. Это напрямую дает легкий способ отсекать неиспользуемый код и обфусцировать его. Как обстоят дела в TeaVM? Таскается весь код или библиотека целиком?
Похоже на имплементацию HATEOAS. А поддерживаются ли Fetch.EAGER и fetchGroups? Например если я хочу вывести сразу одним запросом объекты и содержимое их OneToMany-полей? А параметры к запросам можно передавать?
Интересно в каких именно испанских школах так изучают роботехнику? Разве что в нескольких частных элитных. Сомневаюсь, что когда-нибудь подобное появится в испанских школах, скорей введут курс по винам и хамонам…
Это все справедливо для небольшой компании. В крупных корпорациях дело все обстоит немного по-другому.
1. Менеджер проекта не вправе прямо устанавливать зарплаты, этим занимается департамент кадров. Для подъема зарплаты необходимы более веские основания, нежели «это ключевой человек в моем проекте», такие как занимаемая должность, различные сертификаты, курсы повышения квалификации и тому подобное. Потому как проект может закончиться, а сотрудник с зарплатой остается.
2. Тем не менее, твоя дальнейшая карьера полностью зависит от начальника проекта. Если он заинтересован в твоем прогрессе (чаще всего с целью оставить после себя преемника перед собственным повышением), то все рано или поздно сложится. Однако чаще всего начальник не заинтересован в этом т.к. на определенном этапе требуется совершить переход из техников в менеджеры. А если ты у него ключевая фигура в проекте… объяснять, думаю, не надо.
3. Повышение зарплаты повышает риск быть уволеным. В большой компании всегда есть определенный пул работников без проекта, которых нужно пристроить (особенно во времена кризиса). Если ваша зарплата резко отличается от сотрудников того же профиля, отдел кадров может настоять на вашем увольнении и замене вас в проекте на более «рентабельных».
4. Не ждите персонального подхода. Для корпорации вы — ресурс. Измеренный и оцененный. В проекте ваше место числится например как «Senior Java Developer», а все ваши персональные заслуги и медали остаются за кадром. Поэтому доходит до скандалов, когда менеджер требует в проект конкретного человека, а ему предлагают на выбор других того же профиля, мотивируя тем, что никакой разницы нет.
5. Выше головы не прыгнешь. Компания имеет четкие расценки для специалистов каждого профиля, по которым она может вас продать. Если Вы просите больше, чем стоите минус маржа, вы становитесь нерентабельными.
6. Впринципе, большинству руководящих должностей в большой компании пофиг на свои проекты. Если проект загнется, всегда дадут новый, а неудачу всегда можно списать на внешние факторы.
Давным-давно, еще во время молодости и засилия Windows, я экспериментировал с этим. Был и сейчас есть довольно сносный GNU компилятор для Java (GCJ) и проект GNU classpath с эмуляцией джавовского API, которые на выходе дают бинарник. Вместо свинга использовался SWT. Был даже проект SwingWT с портированными свинговскими виджетами, работающими под SWT. Еще был проект Excelsior Jet, который компилировал джавовский код в бинарник. Тоже не требовал JRE, если не использовался Swing. Сейчас не знаю состояние этих проектов, но тогда мне хватало.
Между прочим, зря минусуете. На днях была подобная ситуация, вылетал по-крупному с NoClassDefFoundError. Думали на ошибку в сборке или ClassLoader. Причем оригинальный Exception не содержался в stacktrace. Поэтому в этом случае правильный код будет не такой тривиальный:
private static class LazyHolder {
private static final Something INSTANCE;
private static final Exception EXCEPTION;
static {
try {
INSTANCE = new Something();
EXCEPTION = null;
} catch ( Exception ex ) {
INSTANCE = null; EXCEPTION = ex;
}
}
}
public static Something getInstance() throws Exception {
if ( LazyHolder.INSTANCE != null )
return LazyHolder.INSTANCE
else throw EXCEPTION;
}
> Все языки программирования, которые я знаю, проводят жесткую грань между методами с именем, типа «append», и операциями, типа "+="
Я не совсем понимаю, чем "+=" лучше слова append? Операции +,-,*,/ идут из алгебры и интуитивно понятны в контексте операций с числами, векторами, etc… Тогда как операции !, /:, :/, ++=, &~ заставляют лезть в дебри API и делают код нечитаемым. Если перегрузка и имеет смысл, то исключительно для алгебраических операций. Scala же по-максимому злоупотребляет везде где только возможно.
> Есть всё же несколько вещей, которые мне не понравились, за чуть более чем шести летний опыт работы со Scala. Вот некоторые из них:
Собственно все то, чем так гордилась Scala коту под хвост ;) Можно много спорить о том, что скала сложна или разумно проста, но есть один неоспоримый факт в пользу первого: отсутствие до сих пор адекватной поддержки IDE. То есть я говору не о подсветке синтаксиса, а о полном понимании контекста кода, автоподстановке, так необходимой в DSL, быстрой дифференциальной компиляции, etc.
К вопросу о сложности. Простота не в том, чтобы как можно короче выразить в коде идею, а в том, чтобы существовал только один способ это сделать. В Scala же как и в Perl-е существует куча вариантов написать одно и то же. Это не есть хорошо, ибо любая свобода — это увеличение хаоса в системе. К тому же есть два постулата:
1. Свобода хороша для тех, кто умеет ей пользоваться.
2. Пользоваться свободой не умеет никто.
Так что выбирайте.
Согласен, сложнее, если все делать правильно. Однако Option был введен искуственно и само его использование опционально, хотя и рекомендуется. Язык не избавился от парадигмы null-ов, даже несмотря на то, что там появились case классы. Мы имеем любой класс MyClass от AnyRef, который сам по себе уже nullable. Плюс еще добавляем Option для явного указания, что его значение опционально. То есть если например метод возвращает MyClass мы не можем сказать, возвращает ли он null или нет. Кто-то пользует Option, кто-то нет, это добавляет неразберихи.
Помимо этого проблема Option-а в том, что Option[Int] не имеет никакого отношения к Int. То есть обычный Int просто так не передать в функцию func( x: Option[Int] ), хотя по идее Option[Int] должен расширять Int. Поэтому последняя тенденция (Kotlin, Ceylon) — встроить в сам язык nullable типы, которые указываются въявную и расширяют содержимые типы.
9. Издавайте и продавайте дидактические материалы о том как стать успешным. Тем самым Вы формируете легенду о себе и своей успешности. ;)
Очень модно учиться успехам бизнеса у американских ребят. Но я не знаю в какой мере описанное будет применимо в среде с другой культурой и менталитетом.
java.util.logging.Logger log4jLog = java.util.logging.Logger.getLogger(«log4jLog»);
->
org.apache.log4j.Logger log4jLog = org.apache.log4j.Logger.getLogger(«log4jLog»);
???
AI-это отдельная тема. Любой AI состоит из функции генерации ходов и оценочной функции. Генерация ходов не представляет собой проблемы, если описан конечный автомат. А вот оценка позиции и хода представляет собой отдельную задачу, которая не имеет ничего общего с описательной частью игры. Она программируется совершенно отдельно, напр. минимаксным алгоритмом. Более того, во многих случаях для AI приходится генерировать отдельно упрощенный граф состояний (для которого не важны промежуточные состояния GUI), а иногда использовать и другую и модель данных.
С точки зрения реализации игры всегда будут три компонента: GUI, модель и контроллер. Модель полностью описывает текущее состояние игры. Контроллер принимает действие пользователя, проверяет валидность, и меняет состояние игры. GUI соответственно отображает состояние и визуализирует ходы. Модель хорошо масштабируется для сети: каждый клиент всегда хранит копию текущего состояния игры, ходы передаются всем игрокам партии, контроллер каждого клиента одинаковым образом актуализирует у себя состояние игры.
Проблема начинается, когда модель игры плохо состыковывается с моделью GUI. Например, в шахматах состояние доски логично хранить ввиде матрицы клеток, где фигуры — значения в клетках. GUI использует обратную модель: обычно список визуальных компонентов фигур, которые хранят внутри свои координаты на доске. Необходимо писать достаточно нетривиальный код, связывающий эти две модели. Хороший способ избежать этого — сразу использовать модель, схожую с GUI. Например для карточных игр универсальная модель — это хранить список из всех карт колоды, с указанием, где она находится в данный момент (в колоде, на руках у пользователя, в «бите», на столе в такой то позиции, etc). Для визуализации хода достаточно лишь вычислить координаты позиции для карты и анимировать соответствующий компонент.
Скелет для контроллера настольных игр достаточно прост в первом приближении. Лучший способ описания контроллера и всей логики игры — конечный автомат (finite state machine). Есть куча библиотек на этот счет, я разработал свою. Но потом оказывается, то GUI для визуального отображения ходов (обычно с анимацией) необходима расширенная информация от контроллера о последнем изменении состояния. Например в случае шахмат — это не просто действие пользователя (какая фигура куда сходила), а был ли ход шахом, рокировкой, съеданием. Поэтому частично логику GUI контроллер частично управляет логикой GUI посредством генерации событий после изменения состояния. В других играх ход игрока может генерировать целый каскад событий. Например в игре в покер ситуация, где игрок пошел all-in (одно единственное событие игрока), открываются карты обоих игроков, затем последовательно все карты флопа, затем производится сравнение комбинаций, затем распределяется выигрыш и после этого дилится новый кон.
В следующем приближении обнаружится, что для многих игр, особенно карточных, состояние игры не одинаково для всех игроков — каждый игрок должен видеть только свои карты и карты на столе. И требуется один особый «серверный» контроллер, которому доступно состояние всех карт (если держать полное состояние на клиенте — моментально сломают). Модель игры становится асимметричной, появляются исключительно «серверные» ходы: сдать карту, бросить кубик, etc. Логика должна уметь синхронизировать состояние серверой модели с состояниеми моделей игроков.
По мере написания игр всплывает еще куча дополнительных нюансов. Обнаруживается, что многие игры помимо основного геймплея имеют раунды и таблицу очков, и хотелось бы иметь некий общий шаблон для этого. В онлайн играх очень актуально решить что делать, если пользователь отконнектился: завершить игру, продолжать играть за него машине, продолжить игру с меньшим числом игроков, etc. Также неплохо внедрить логику таймаута на ход: например делать машиной случайный ход. Для этого контроллер должен уметь гененировать всевозможные ходы для данной позиции (которые также можно использовать для валидации хода пользователя). И еще куча нюансов.
Вобщем, что я хотел сказать. Задача написания универсального движка для игр не сводится к созданию языка для описания игровой логики, а к созданию иерархии шаблонов общим функционалом. И написаны они могут быть написаны на любом языке. Для этого нужно проанализировать большое количество игр, разбить на классы (карточные, досочные, настольные). Для каждого из компонентов (GUI, контроллер и модель) выделить абстрактный функционал и написать расширяемые шаблоны. Тем не менее, для любой игры 80% времени всегда будет занимать создание GUI.
Ух ты! Этакий Капитан Америка прямо!
Практика показывает, что западный программист — это:
— хреновый инженер, т.к. программирование для него — это инструмент зарабатывания денег и не лежит в области его непосредственных интересов. Либо его знания слишком поверхностны, либо слишком узкоспециализированы. Зачем мне знать сверх того, что я могу продать?
— посредственный бизнесмен. Да, в штатах с детства учат подавать и продавать себя, но точно также мало кто на это ведется. Прежде чем посредственному бизнесмену позволят стать успешным, он должен будет доказать свою лояльность, лизать задницы начальства и рвать свою. И то не факт, что что-то перепадет.
— прямолинейный и твердолобый политик. Все его намерения и притязания ясны с первых же минут общения, и не отличаются особой изощренностью. Хочет денег и продвижения.
— совершенно никакой философ. Зациклен на карьере и собственной выгоде. Полет мысли ограничен исключительно земными благами.
Русский инженер — это филосов и исследователь. Западный инженер — это ремесленник.
P.S. А если серьезно, то очередное идеализирование устоявшихся стереотипов.
P.P.S. >А в США ушлые мамочки пихают своих детишек в программисты.
Юриспруденция, менеджмент, медицина.
Чистейший американизм. Две вещи, которые я ненавижу: отсутствие внятного описания продукта и отсутствие цены. Страницы пестрят совершенно бесполезными заверениями вроде «наш продукт — вазелин для вашего бизнеса» (не понимаю, неужели люди до сих пор на это покупаются?) При этом информацию о реальном функционале продукта найти бывает очень сложно, а иногда вообще невозможно. Дается лишь общее описание в стиле «универсальный решатель бизнес проблем для тех, кто идет в ногу со временем», без каких-либо деталей. Для клиент становится невозможно оценить чем ваш продукт лучше конкурентов. При таком подходе можно Ладу продать по цене БМВ (что собственно часто и бывает в мире IT) — задачи схожие, описания нет, сравнивать нечего.
Поэтому не надо держать клиента за идиота. Скажи конкретно, что ты продаешь и сколько это стоит, а он уже решит надо это ему или нет, как он это будет использовать и сколько сможет сэкономить.
> 51 Ценовые иллюзии вместо обычных цен
Тоже американизм. Тут либо тебя держат за идиота, неумеющего производить элементарные математические действия, либо ты не идиот, и понимаешь, что таким нехитрым способом тобой пытаются манипулировать, но все-равно с этим соглашаешься. Не знаю как американцам, мне такое портит впечатление.
Группа инженеров, работая в дряхлой компании, загорается новой идеей, делает прототип и презентует начальству. Начальство настроено скептически: «это не наш профиль», «тут нет денег», «бизнес-модель не отработана», «молодцы, ребята! так держать!», etc… Разочаровавшись, инженеры открывают свою компанию, на коленках в свободное время делают пробную версию, увольняются из корпорации, и пытаются раскрутить продукт. Контакты с клиентами отстались, а гибкость позволяет быстро выйти на самоокупаемость.
Более того, все программы снабжены базами финалов, до 6-й или 7-й фигуры. Во всех подобных чемпионатах, игра заканчивается, если партия входит в финал, и компьютер показывает результат. Однако результат верен, если человек не ошибется в финале, что даже для гроссмейстеров далеко не всегда верно.
Обертки можно генерировать автоматически из W3C IDL. По-моему так TypeScript по-началу делал.
Интересует несколько вещей:
1. За счет чего все-таки достигается производительность? Разработчики GWT божились, что из .class нельзя получить эффективный JS, что и доказывают проекты вроде Eclipse Java2Script?
2. Насколько я понял, проект должен включать в себя какой-нибудь API для работы с платформой браузера: DOM, Canvas, etc...?
3. Есть какие-нибудь средства для включения нативного JS-кода, как например JSNI?
4. Можно ли расширять или дополнять возможности поддерживаемого API Java не суясь в TeaVM? Что-то вроде GWT super-package?
5. Поскольку в GWT отсутствует рефлексия, все объявления статические. Это напрямую дает легкий способ отсекать неиспользуемый код и обфусцировать его. Как обстоят дела в TeaVM? Таскается весь код или библиотека целиком?
1. Менеджер проекта не вправе прямо устанавливать зарплаты, этим занимается департамент кадров. Для подъема зарплаты необходимы более веские основания, нежели «это ключевой человек в моем проекте», такие как занимаемая должность, различные сертификаты, курсы повышения квалификации и тому подобное. Потому как проект может закончиться, а сотрудник с зарплатой остается.
2. Тем не менее, твоя дальнейшая карьера полностью зависит от начальника проекта. Если он заинтересован в твоем прогрессе (чаще всего с целью оставить после себя преемника перед собственным повышением), то все рано или поздно сложится. Однако чаще всего начальник не заинтересован в этом т.к. на определенном этапе требуется совершить переход из техников в менеджеры. А если ты у него ключевая фигура в проекте… объяснять, думаю, не надо.
3. Повышение зарплаты повышает риск быть уволеным. В большой компании всегда есть определенный пул работников без проекта, которых нужно пристроить (особенно во времена кризиса). Если ваша зарплата резко отличается от сотрудников того же профиля, отдел кадров может настоять на вашем увольнении и замене вас в проекте на более «рентабельных».
4. Не ждите персонального подхода. Для корпорации вы — ресурс. Измеренный и оцененный. В проекте ваше место числится например как «Senior Java Developer», а все ваши персональные заслуги и медали остаются за кадром. Поэтому доходит до скандалов, когда менеджер требует в проект конкретного человека, а ему предлагают на выбор других того же профиля, мотивируя тем, что никакой разницы нет.
5. Выше головы не прыгнешь. Компания имеет четкие расценки для специалистов каждого профиля, по которым она может вас продать. Если Вы просите больше, чем стоите минус маржа, вы становитесь нерентабельными.
6. Впринципе, большинству руководящих должностей в большой компании пофиг на свои проекты. Если проект загнется, всегда дадут новый, а неудачу всегда можно списать на внешние факторы.
Я не совсем понимаю, чем "+=" лучше слова append? Операции +,-,*,/ идут из алгебры и интуитивно понятны в контексте операций с числами, векторами, etc… Тогда как операции !, /:, :/, ++=, &~ заставляют лезть в дебри API и делают код нечитаемым. Если перегрузка и имеет смысл, то исключительно для алгебраических операций. Scala же по-максимому злоупотребляет везде где только возможно.
> Есть всё же несколько вещей, которые мне не понравились, за чуть более чем шести летний опыт работы со Scala. Вот некоторые из них:
Собственно все то, чем так гордилась Scala коту под хвост ;) Можно много спорить о том, что скала сложна или разумно проста, но есть один неоспоримый факт в пользу первого: отсутствие до сих пор адекватной поддержки IDE. То есть я говору не о подсветке синтаксиса, а о полном понимании контекста кода, автоподстановке, так необходимой в DSL, быстрой дифференциальной компиляции, etc.
К вопросу о сложности. Простота не в том, чтобы как можно короче выразить в коде идею, а в том, чтобы существовал только один способ это сделать. В Scala же как и в Perl-е существует куча вариантов написать одно и то же. Это не есть хорошо, ибо любая свобода — это увеличение хаоса в системе. К тому же есть два постулата:
1. Свобода хороша для тех, кто умеет ей пользоваться.
2. Пользоваться свободой не умеет никто.
Так что выбирайте.
Помимо этого проблема Option-а в том, что Option[Int] не имеет никакого отношения к Int. То есть обычный Int просто так не передать в функцию func( x: Option[Int] ), хотя по идее Option[Int] должен расширять Int. Поэтому последняя тенденция (Kotlin, Ceylon) — встроить в сам язык nullable типы, которые указываются въявную и расширяют содержимые типы.