Надо отметить, что в SVN, конечно, есть ветки, но сделаны они, видимо, для другого, и поэтому плохо приспособлены для того, чтобы их сливать в trunk.
Ключевое слово выделено жирным. Как бы надо немного разобраться с трехсторонним мерджем и все становится просто супер.
Эта же ветка заливалась на продакшн. Главное неудобство здесь — то, что если мы производим какие-то изменения, или разрабатываем новый функционал, мы вынуждены либо сидеть и не коммитить до тех пор, пока задача не будет доделана до конца, либо (если нам нужна помощь коллеги), закоммитить недоделанный функционал, как есть, сделав таким образом trunk непригодным к заливке на продакшн. Особенно это неприятно, если новый функционал делается не один день, а в это время возникает необходимость что-нибудь срочно починить в рабочей системе.
Я бы таких горе-разработчиков уволил на хер. Это НЕ вопрос используемой системы контроля версий, а построенного процесса и дисциплины.
hetzner, 1 und 1, clara — 50-70 ms. Забыл сказать, трафик бесплатный, скорость падает до 10 мегабит после превышения терабайта-двух в месяц, в зависимости от тарифа. Бесплатная подсеть на 8 айпишников :) Вам решать.
Сервера приложений там, где сгодился бы сервлет-контейнер,
контейнер — там, где прекрасно себя чувствовал бы Jetty.
EJB(2, 3) вместо Spring.
Бинарный ремоутинг там, где сгодились бы HTTP-запросы.
SOAP вместо REST.
GWT вместо фронтенда на jQuery (или подобном) к REST-бекенду.
Чисто джавские MVC-фреймворки вместо Grails.
Толстые клиенты на RCP и Swing вместо Flex/AIR.
Подключаемые библиотеки для работы с картинками вместо внешнего ImageMagick.
Работа с файлами и окружением из кода вместо шелл-скриптов.
Можно добавлять, например, интересующие ресурсы и затем пользоваться _поиском_, это сильно облегчает отслеживание новостей по интересующему продукту, например.
112 вещь крайне ненадежная, недавно нужны были — все время, которое потребовалось, чтобы разобраться самим, там играла музычка, и 5 минут после этого тоже. Выходной, середина дня. Хотел потом все же дозвониться и устроить кому-нибудь вынос мозга, но в итоге просто забил — может быть, зря.
Достаточно учебника по языку + классам SE. Джава-разработчик, не знающий английского, в реальной жизни функционировать просто неспособен. Разумеется, есть исключения, которые занимаются какой-то очень специальной областью типа вычислений или участвуют в отдельной части очень большого проекта, и их область деятельности ограничивается языком и собственными библиотеками проекта, однако большинство задач предполагает использование разнообразных подходов, компонент, сторонних приложений, объем знаний по которым настолько огромен и так часто обновляется, что перевод даже единиц процентов его не представляется возможным.
Очень надеюсь, что все эти красоты можно будет отключить и использовать классическую тему оформления (не синюшную XP а ту, которая получается, если все настройки отображения поставить в «наибольшую производительность»)
> Вы запускаете FTP-клиента, перетаскиваете gif-ки и css-ки с левой панели на правую и, весь такой довольный, открываете вебсайт в своем любимом браузере…
бардак начался уже здесь, нужно было воспользоваться svn или другим механизмом, который поддерживает целостность версии.
Я провел два замечательных года в одной очень крупной государственной компании. Зарплата была не очень большая, зато платили ее с точностью до нескольких минут, работал «на них» я процентов 20 времени, а все остальное посвящал самообразованию и поиску халтуры.
Никогда в жизни не пошел бы «работать в интегратора» (разве уж от совсем отчаянного голода) — глубоко внутри я убежден, что все они занимаются какой-то херотой (ну кому нужны эти дурацкие информационные системы? мне от них ни тепло, ни холодно), а корпоративный дух мне отвратителен.
В маленькой компании, как ни крути, ты оказываешься ближе к источнику бабла и возможностей, чем в большой. Если нужно набраться каких-то скиллов или выходов для того, чтобы сделать что-то свое, в большой конторе делать нечего.
Однако есть еще один вариант, самый желанный для любого технаря — компания, которая не делает херни. Если есть возможность — нужно идти туда, потому что редко предоставляется возможность делать что-то не только ради денег, но еще и для собственного кайфа, особенно если это какая-то новая разработка, какой еще в мире не существует.
Нельзя называть «уязвимостью» использование произвольного клиентского устройства. Проблема — в протоколе. Если я что-то сделаю с The Bat и начну получать чужие письма, проблема все равно будет не с The Bat, а с сервером электронной почты.
РБК себя уже несколько месяцев как плохо себя чувствует, и представляет собой сейчас нечто худшее, чем студия из директора и манагера. Уверен, что в случае с квипом творится безобразный бардак, о чем, собственно, произошедший инцидент и свидетельствует.
Ключевое слово выделено жирным. Как бы надо немного разобраться с трехсторонним мерджем и все становится просто супер.
Эта же ветка заливалась на продакшн. Главное неудобство здесь — то, что если мы производим какие-то изменения, или разрабатываем новый функционал, мы вынуждены либо сидеть и не коммитить до тех пор, пока задача не будет доделана до конца, либо (если нам нужна помощь коллеги), закоммитить недоделанный функционал, как есть, сделав таким образом trunk непригодным к заливке на продакшн. Особенно это неприятно, если новый функционал делается не один день, а в это время возникает необходимость что-нибудь срочно починить в рабочей системе.
Я бы таких горе-разработчиков уволил на хер. Это НЕ вопрос используемой системы контроля версий, а построенного процесса и дисциплины.
контейнер — там, где прекрасно себя чувствовал бы Jetty.
EJB(2, 3) вместо Spring.
Бинарный ремоутинг там, где сгодились бы HTTP-запросы.
SOAP вместо REST.
GWT вместо фронтенда на jQuery (или подобном) к REST-бекенду.
Чисто джавские MVC-фреймворки вместо Grails.
Толстые клиенты на RCP и Swing вместо Flex/AIR.
Подключаемые библиотеки для работы с картинками вместо внешнего ImageMagick.
Работа с файлами и окружением из кода вместо шелл-скриптов.
www.i4i.com/x4o.htm
бардак начался уже здесь, нужно было воспользоваться svn или другим механизмом, который поддерживает целостность версии.
ничего неприличного
Никогда в жизни не пошел бы «работать в интегратора» (разве уж от совсем отчаянного голода) — глубоко внутри я убежден, что все они занимаются какой-то херотой (ну кому нужны эти дурацкие информационные системы? мне от них ни тепло, ни холодно), а корпоративный дух мне отвратителен.
В маленькой компании, как ни крути, ты оказываешься ближе к источнику бабла и возможностей, чем в большой. Если нужно набраться каких-то скиллов или выходов для того, чтобы сделать что-то свое, в большой конторе делать нечего.
Однако есть еще один вариант, самый желанный для любого технаря — компания, которая не делает херни. Если есть возможность — нужно идти туда, потому что редко предоставляется возможность делать что-то не только ради денег, но еще и для собственного кайфа, особенно если это какая-то новая разработка, какой еще в мире не существует.