думаю тут все просто
на западе компы, софт и тд это просто работа
ну вот так случилось, что я знаю чуть больше почему бы и не ответить
когда отвечу хорошо и содержательно, то я смогу продемонстрировать свои знания и когда мне надо будет искать работу я смогу ссылаться на эти материалы, что увеличивает мои шансы трудоустроиться по сравнению с тем, кто не пишет ничего
в России софт все еще отрасль избранных, это и хорошо и плохо одновременно
хорошо — идет отбор
плохо — влияние персоналий велико
если у вас есть open source проект плюс много толковых постов — у вас всегда будет работа
аналогию можно провести с аэропортом
там проверяют всех и это не случайно — персонал обеспечивает периметр безопасности
с информацией тоже самое — нужно обеспечить отсутствие доступа — периметр
при этом сохранив рабочий процесс
именно поэтому у девелоперов не должно быть доступа к продакшн
Хотелось бы чтобы эта IDE была чем то средним между возможностью писать код и источником информации по структуре базы.
Написать запрос не проблема, а вот знать, что таблица в себе содержит и как она относится к другим таблицам это иногда загадка дня на три.
То есть этакая «база знаний» о базе данных. После года в продакшн и пары перешедших на другую работу dba очень тяжело искать информацию о структуре объектов.
Хорошая попытка была реализована в Toad Data Modeler, но там все мышкой и писать запросы не получится.
Хотелось бы иметь IDEA но для базы, когда все «под руками» и понятно как писать запрос для реализации поставленной задачи.
Спасибо за хорошие продукты.
А почему нельзя оставить факт владения? Зачем удалять то, что работает?
Что будет если просто добавить подписную лицензию к существующим за меньшие деньги?
Если лицензия поменяется, то смысла покупать новую нет потому, что «сокращаются» возможности.
Jetbrains на самом деле переносит свои риски (риск не преобретения) на пользователей (теперь пользователям надо искать средства).
Не очень красиво, но ожидаемо.
FindBugs отличный инструмент для поиска ошибок на уровне кода.
Я работаю Performance Analyst (высокооплачиваемый дворник вычищающий код) и часть работы это просмотр кода и исправление ошибок. Когда вы приходите к клиенту, вам говорят буквально «вот система сделай ее быстрее». Для того чтобы хоть немного оценить масштаб работы нужно просмотреть код. Понятно, что документации и тестов нет. И как раз в этой ситуации помогает статический анализатор. Если код более менее чистый, то сразу можно переходить на архитектуру (как работает, топология и тд).
Интеграция FindBugs с maven это скорее уже на окончание работы, чтобы не допускать ошибок в будущем.
Хранить много данных и считать по ним быстро нужно далеко не каждой организации. В сельскую библиотеку такая система не нужна. Такая система нужна тем, кому нужна скорость и кто готов за нее платить. Я видел использование Coherence только в банках.
И потом, если бы такую цену не платили то Coherence стоила бы меньше.
По поводу размера. Ограничения на размер нет. Просто нужно понимать, как система себя будет вести в каждом конкретном случае.
Это не автоперевод. Цель была дать общее определение терминов в начальной статье. Все детали работы и реализации в одну статью не поместятся.
Ноды хранения держат данные. Ваша цель сделать так, чтобы они не упали по OOM. Поэтому базовые вычисления разумно выполнять на этих нодах, а вот аналитику по базовым вычислениям выполнять на вычислительных нодах. Вы можете разнести по разным машинам если хотите. Главное, что вы не передаете все данные какие есть для вычислений на клиенте. У вас есть возможность делать промежуточные вычисления.
По поводу сканирования. Предположим у вас есть класс
public class Person implements PortableObject {
private String firstName;
private String lastName;
....................
public void readExternal(PofReader pofReader) throws IOException {
firstName = pofReader.readString(0);
lastName = pofReader.readString(1);
}
public void writeExternal(PofWriter pofWriter) throws IOException {
pofWriter.writeString(0, firstName);
pofWriter.writeString(1, lastName);
}
}
В этом случае сначала будет записан firstName, а за ним будет идти lastName.
Теперь у вас есть данные в кеше и есть задача выбрать только lastName. Вы пишете ValueExtractor. Так вот когда экстрактор будет работать, он просканирует массив с начала, найдет lastName и вернет его.
Именно эта мысль была заключена во фразе «cканирование массива происходит последовательно».
Итак, по прошествии суток видно, что люди готовы тратить свое время на то, чтобы написать статью. Получается, что деньги не являются мотивом для написания статей.
Так зачем тогда нужно привносить идею денег?
1000 = 500 + 500
500/50 = 10 рублей за клик
написать статью по времени на отвлеченную тему минут 20 (если вообще есть о чем писать)
автору 50% и клик по 10 рублей
еще проще
делаем агрегатор по новостям (ходим на форумы и собираем интересные вопросы/ответы)
20 минут тратить не надо
получаем content delivery network коих написано не мало и чтение коих не радует
я к чему это все
Жванецкий хорошо сказал «ПисАть как и пИсать нужно тогда, когда терпеть уже невозможно!»
монетизация написания статей убивает всю идею авторства
через 2-3 года останутся только статьи компаний которым нужна реклама
работаю в Лондоне 8 лет (6 лет на постоянной работе и 2 года контрактником)
заметил такую особенность
хотя и кажется, что Лондон большой, на самом деле все друг друга знают и обмениваются информацией о работниках. Поэтому уходить «сжигая мосты» не рекомендуется.
После 3-4 лет хорошей работы найти новую не соcтавит труда. Достаточно будет написать письмо знакомым о поиске работы. В этом случае уровень оплаты будет выше, потому что не надо платить агенству по найму.
агенства получают как правило 10% от дневной оплаты контрактника или 2000 — 5000 GBP за постоянного работника.
при переходе с одной постоянной работы на другую вам не повысят зарплату более чем на 10 %
в работе контрактником меня особенно привлекает техническая направленность задач и никакой офисной политики
Рискую навлечь на себя волну негодования, но все же
работал в отделении швейцарского банка в демократичной стране
так вот у них даже в пределах одного банка информация идет только в сторону Швейцарии
обратно — никак
я к чему это все — есть правила и эти правила не мы устанавливаем
если умный — найдешь как решить проблему
а нет — значит не надо это тебе
в этом банке тоже были правила, но нашлась лазейка (законодательная, не техническая) и проблема была решена
правда когда нашли то правила ужесточили
в моём представлении idea хороший инструмент для поставленой задачи
если посмотреть на слоган “программировать с удовольствием!”, то удовольствие идет как раз от того, что все удобно настроено для задачи которую вы решаете
монетизировать платформу с помощью платных плагинов, как по мне, так перебор
в качестве эксперимента я ставил плагины для разных языков на java ide
и как результат — не то
вроде и синтаксис подсвечивает и редактор нормальный — но не удобно, удовольствия нет
как следствие — все эти плагины удаляются
я готов платить деньги за инструмент который помогает решать узко специализированную задачу
а не хочу, чтобы ide варила мне кофе
сделайте с/с++ ide и я сразу же его куплю
сам я программирую на java (server side) и с/с++ (unix)
мнение пользователей может не совпадать с мнением производителя
мы пользовались TradeSignal www.tradesignal.de/
в этой системе очень просто «подсовывать» свои данные
на одном графике трейдер имел возможность смотреть
Realtime Bloomberg, базовые данные и внутреннюю аналитику банка
например (для торговли электричеством)
курс GBP/EUR, сезонную загрузку электростанций, прогноз погоды и кривые построенные квантами
то есть акцент переводится с торговли как таковой на многомерный анализ данных
банк имеет свою систему которая копирует файлы с серверов на которых тестируют на продакшн
TEST — UAT — PROD
разработчики могут выложить версию только на TEST
PROD под контролем администраторов
в случае исправления ошибки весь цикл повторяется
Работаю в банках вот уже 7 лет. В общем со статьей согласен, но есть и исключения.
Для того, чтобы найти нормальную работу в банке надо хоть немного понимать как он устроен.
В любом банке есть: фронт офис, мидл офис и бек офис.
фронт офис — это парни «на передовой». Это те, кто зарабатывают деньги для банка. Здесь решение дожно быть предоставлено вчера (сегодня вечером может быть уже не надо), должно работать быстро и об интеграции в существующие системы как правило думать не надо.
мидл офис — это парни которые проверяют, что же фронт офис «настрелял» за день. Тут уже надо думать более масштабно и понимать как различные системы взаимодействуют друг с другом. PnL репортинг как раз работает этом уровне.
бек офис — это в основном репорты, проверка и «чистка» данных. Здесь можно считать медленно, но по большому объему данных.
Я работал во фронт и мидл офисах. Бек офис — это засилье команд из Индии, там нечего делать.
Мне повезло и команда на текущем проекте хорошая и работа интересная на несколько лет вперед.
Проект как раз на стыке фронт и мидл офисов.
По поводу качества кода все немного тоньше и деликатнее. Я разговаривал с ребятями на эту тему и уверяю вас они умеют писать и юнит тесты и чистый код.
НО
Тот, кто платит деньги думает о том как быстро окупится решение (чем больше времени разработка тем дороже). Отсюда следствие — чем быстрее сделал, тем ты лучше. Как результат — безумные патчи на систему, отсутствие документации/юнит тестов и все остальные прелести описанные в статье.
Через 3-4 года такой разработки проект переписывают заново, потому что с определенного момента патчи уже невозможно поставить.
хорошая книга
Java Performance (http://www.amazon.com/Java-Performance-Charlie-Hunt/dp/0137142528)
протым языком написано что и как работает
единственное что смущает это копии экрана в книге
думаю из-за этого книга «весит» 720 страниц
но если картинки пропускать то нормально
Я работал в Бангалоре пол года. Это был достаточно интересный опыт общения с другой культурой.
Основные проблемы:
1. Иерархии — нельзя сказать человеку который стоит выше тебя, что он не прав. Дело доходило иногда до абсурда когда обсуждали архитектуру новой части проекта, то на вопрос «есть ли вопросы или замечания» ответ всегда был такой «раз ты архитектор, то как ты сказал так и будем делать». У русских нет этих барьеров и на этапе обсуждения, как правило, всегда была дискуссия.
2. IT рынок раздут и люди идут туда потому, что вокруг нищета. Очень много случайных людей. Это приводит к тому, что знания поверхностные и нет понимания «как все это там» работает. Отсюда «пустые» резюме и четкая ориентировка на деньги. Если найдется более высокая зарплата то человек уйдет сразу же.
3. Постоянные «кидалова». Одна из схем выглядит следующим образом. Западная компания объявляет тендер на разработку чего то. Компания из Индии выставляет цену ниже себестоимости. Все уходят они остаются. За пол года пишется что-то невразумительное отдаленно напоминающее оригинальный проект. Оно естесственно не работает и заказчику предлагается пригласить разработчиков «on site» где выставляется цена превышающая цену локального контрактника на 10-50%
Все, клиент попал в сети.
И таких схем много. Нужно постоянно быть в напряжении и следить за тем, что происходит с удаленной командой.
4. В конфликтных ситуациях в мультикультурных командах образуют группы и даже если участник спора не прав все его защищают. Как следствие найти причину и устранить достаточно сложно.
Вопрос: Почему сервер упал?
Ответ: Ты не переживай он сейчас все запустит.
Мне нужно узнать «почему»…
5. Постоянные «стукачества» начальству. Как следствие внутренние конфликты в команде и разделение на мы и они. Качество разработки падает.
Если суммировать, то у меня скорее негативный опыт, чем позитивный.
С Польшей/Россией работать проще и результат работы более прогнозируемый.
на западе компы, софт и тд это просто работа
ну вот так случилось, что я знаю чуть больше почему бы и не ответить
когда отвечу хорошо и содержательно, то я смогу продемонстрировать свои знания и когда мне надо будет искать работу я смогу ссылаться на эти материалы, что увеличивает мои шансы трудоустроиться по сравнению с тем, кто не пишет ничего
в России софт все еще отрасль избранных, это и хорошо и плохо одновременно
хорошо — идет отбор
плохо — влияние персоналий велико
если у вас есть open source проект плюс много толковых постов — у вас всегда будет работа
аналогию можно провести с аэропортом
там проверяют всех и это не случайно — персонал обеспечивает периметр безопасности
с информацией тоже самое — нужно обеспечить отсутствие доступа — периметр
при этом сохранив рабочий процесс
именно поэтому у девелоперов не должно быть доступа к продакшн
Написать запрос не проблема, а вот знать, что таблица в себе содержит и как она относится к другим таблицам это иногда загадка дня на три.
То есть этакая «база знаний» о базе данных. После года в продакшн и пары перешедших на другую работу dba очень тяжело искать информацию о структуре объектов.
Хорошая попытка была реализована в Toad Data Modeler, но там все мышкой и писать запросы не получится.
Хотелось бы иметь IDEA но для базы, когда все «под руками» и понятно как писать запрос для реализации поставленной задачи.
Спасибо за хорошие продукты.
Что будет если просто добавить подписную лицензию к существующим за меньшие деньги?
Если лицензия поменяется, то смысла покупать новую нет потому, что «сокращаются» возможности.
Jetbrains на самом деле переносит свои риски (риск не преобретения) на пользователей (теперь пользователям надо искать средства).
Не очень красиво, но ожидаемо.
Operating Systems: Internals and Design Principles
www.amazon.co.uk/dp/0133805913/ref=pe_385721_37038051_TE_dp_1
Описано не только как сделано, но и почему. Сравниваются возможности разных операционных систем, как устроены планировщики задач и тд
Я работаю Performance Analyst (
высокооплачиваемый дворник вычищающий код) и часть работы это просмотр кода и исправление ошибок. Когда вы приходите к клиенту, вам говорят буквально «вот система сделай ее быстрее». Для того чтобы хоть немного оценить масштаб работы нужно просмотреть код. Понятно, что документации и тестов нет. И как раз в этой ситуации помогает статический анализатор. Если код более менее чистый, то сразу можно переходить на архитектуру (как работает, топология и тд).Интеграция FindBugs с maven это скорее уже на окончание работы, чтобы не допускать ошибок в будущем.
И потом, если бы такую цену не платили то Coherence стоила бы меньше.
По поводу размера. Ограничения на размер нет. Просто нужно понимать, как система себя будет вести в каждом конкретном случае.
Ноды хранения держат данные. Ваша цель сделать так, чтобы они не упали по OOM. Поэтому базовые вычисления разумно выполнять на этих нодах, а вот аналитику по базовым вычислениям выполнять на вычислительных нодах. Вы можете разнести по разным машинам если хотите. Главное, что вы не передаете все данные какие есть для вычислений на клиенте. У вас есть возможность делать промежуточные вычисления.
По поводу сканирования. Предположим у вас есть класс
В этом случае сначала будет записан firstName, а за ним будет идти lastName.
Теперь у вас есть данные в кеше и есть задача выбрать только lastName. Вы пишете ValueExtractor. Так вот когда экстрактор будет работать, он просканирует массив с начала, найдет lastName и вернет его.
Именно эта мысль была заключена во фразе «cканирование массива происходит последовательно».
Так зачем тогда нужно привносить идею денег?
500/50 = 10 рублей за клик
написать статью по времени на отвлеченную тему минут 20 (если вообще есть о чем писать)
автору 50% и клик по 10 рублей
еще проще
делаем агрегатор по новостям (ходим на форумы и собираем интересные вопросы/ответы)
20 минут тратить не надо
получаем content delivery network коих написано не мало и чтение коих не радует
я к чему это все
Жванецкий хорошо сказал «ПисАть как и пИсать нужно тогда, когда терпеть уже невозможно!»
монетизация написания статей убивает всю идею авторства
через 2-3 года останутся только статьи компаний которым нужна реклама
но это мое сугубо личное мнение
заметил такую особенность
хотя и кажется, что Лондон большой, на самом деле все друг друга знают и обмениваются информацией о работниках. Поэтому уходить «сжигая мосты» не рекомендуется.
После 3-4 лет хорошей работы найти новую не соcтавит труда. Достаточно будет написать письмо знакомым о поиске работы. В этом случае уровень оплаты будет выше, потому что не надо платить агенству по найму.
агенства получают как правило 10% от дневной оплаты контрактника или 2000 — 5000 GBP за постоянного работника.
при переходе с одной постоянной работы на другую вам не повысят зарплату более чем на 10 %
в работе контрактником меня особенно привлекает техническая направленность задач и никакой офисной политики
работал в отделении швейцарского банка в демократичной стране
так вот у них даже в пределах одного банка информация идет только в сторону Швейцарии
обратно — никак
я к чему это все — есть правила и эти правила не мы устанавливаем
если умный — найдешь как решить проблему
а нет — значит не надо это тебе
в этом банке тоже были правила, но нашлась лазейка (законодательная, не техническая) и проблема была решена
правда когда нашли то правила ужесточили
но главное что? препятствие побудило решение
прямо дзен какой-то
если посмотреть на слоган “программировать с удовольствием!”, то удовольствие идет как раз от того, что все удобно настроено для задачи которую вы решаете
монетизировать платформу с помощью платных плагинов, как по мне, так перебор
в качестве эксперимента я ставил плагины для разных языков на java ide
и как результат — не то
вроде и синтаксис подсвечивает и редактор нормальный — но не удобно, удовольствия нет
как следствие — все эти плагины удаляются
я готов платить деньги за инструмент который помогает решать узко специализированную задачу
а не хочу, чтобы ide варила мне кофе
сделайте с/с++ ide и я сразу же его куплю
сам я программирую на java (server side) и с/с++ (unix)
мнение пользователей может не совпадать с мнением производителя
в этой системе очень просто «подсовывать» свои данные
на одном графике трейдер имел возможность смотреть
Realtime Bloomberg, базовые данные и внутреннюю аналитику банка
например (для торговли электричеством)
курс GBP/EUR, сезонную загрузку электростанций, прогноз погоды и кривые построенные квантами
то есть акцент переводится с торговли как таковой на многомерный анализ данных
TEST — UAT — PROD
разработчики могут выложить версию только на TEST
PROD под контролем администраторов
в случае исправления ошибки весь цикл повторяется
Для того, чтобы найти нормальную работу в банке надо хоть немного понимать как он устроен.
В любом банке есть: фронт офис, мидл офис и бек офис.
фронт офис — это парни «на передовой». Это те, кто зарабатывают деньги для банка. Здесь решение дожно быть предоставлено вчера (сегодня вечером может быть уже не надо), должно работать быстро и об интеграции в существующие системы как правило думать не надо.
мидл офис — это парни которые проверяют, что же фронт офис «настрелял» за день. Тут уже надо думать более масштабно и понимать как различные системы взаимодействуют друг с другом. PnL репортинг как раз работает этом уровне.
бек офис — это в основном репорты, проверка и «чистка» данных. Здесь можно считать медленно, но по большому объему данных.
Я работал во фронт и мидл офисах. Бек офис — это засилье команд из Индии, там нечего делать.
Мне повезло и команда на текущем проекте хорошая и работа интересная на несколько лет вперед.
Проект как раз на стыке фронт и мидл офисов.
По поводу качества кода все немного тоньше и деликатнее. Я разговаривал с ребятями на эту тему и уверяю вас они умеют писать и юнит тесты и чистый код.
НО
Тот, кто платит деньги думает о том как быстро окупится решение (чем больше времени разработка тем дороже). Отсюда следствие — чем быстрее сделал, тем ты лучше. Как результат — безумные патчи на систему, отсутствие документации/юнит тестов и все остальные прелести описанные в статье.
Через 3-4 года такой разработки проект переписывают заново, потому что с определенного момента патчи уже невозможно поставить.
Java Performance (http://www.amazon.com/Java-Performance-Charlie-Hunt/dp/0137142528)
протым языком написано что и как работает
единственное что смущает это копии экрана в книге
думаю из-за этого книга «весит» 720 страниц
но если картинки пропускать то нормально
Основные проблемы:
1. Иерархии — нельзя сказать человеку который стоит выше тебя, что он не прав. Дело доходило иногда до абсурда когда обсуждали архитектуру новой части проекта, то на вопрос «есть ли вопросы или замечания» ответ всегда был такой «раз ты архитектор, то как ты сказал так и будем делать». У русских нет этих барьеров и на этапе обсуждения, как правило, всегда была дискуссия.
2. IT рынок раздут и люди идут туда потому, что вокруг нищета. Очень много случайных людей. Это приводит к тому, что знания поверхностные и нет понимания «как все это там» работает. Отсюда «пустые» резюме и четкая ориентировка на деньги. Если найдется более высокая зарплата то человек уйдет сразу же.
3. Постоянные «кидалова». Одна из схем выглядит следующим образом. Западная компания объявляет тендер на разработку чего то. Компания из Индии выставляет цену ниже себестоимости. Все уходят они остаются. За пол года пишется что-то невразумительное отдаленно напоминающее оригинальный проект. Оно естесственно не работает и заказчику предлагается пригласить разработчиков «on site» где выставляется цена превышающая цену локального контрактника на 10-50%
Все, клиент попал в сети.
И таких схем много. Нужно постоянно быть в напряжении и следить за тем, что происходит с удаленной командой.
4. В конфликтных ситуациях в мультикультурных командах образуют группы и даже если участник спора не прав все его защищают. Как следствие найти причину и устранить достаточно сложно.
Вопрос: Почему сервер упал?
Ответ: Ты не переживай он сейчас все запустит.
Мне нужно узнать «почему»…
5. Постоянные «стукачества» начальству. Как следствие внутренние конфликты в команде и разделение на мы и они. Качество разработки падает.
Если суммировать, то у меня скорее негативный опыт, чем позитивный.
С Польшей/Россией работать проще и результат работы более прогнозируемый.