Спасибо за видео, вроде все логично, и до всего можно додуматься самому, но тут собрано в одном месте, и это хорошо — stratoplan.ru/ngt/nuzhda.html
Я тут подумал, собеседование в компанию это ведь тоже манипуляция:
* Просят заполнить резюме по своей форме — трата времени и энергии
* Просят сделать тестовое задание — трата времени и энергии
* Просят несколько раз приехать в офис — трата времени и энергии
* Обещают премии квартальные/годовые/проектные если будешь хорошо работать — обещание денег без конкретики
* Ожидание собеседующих или заполнение опросника — трата времени и энергии
* Обещание повышения зарплаты/должности после испытательного — обещание денег без конкретики
* Рассказ о лидере рынка и крупных заказчиках — манипуляция эмоциями
* Очень умные вопросы из книжек и троллинг от собеседующих — манипуляция эмоциями
* Компания сообщает ответ не сразу — манипуляция эмоциями
* Компания не отвечает неподходящим кандидатам или отвечает через месяц-два — манипуляция эмоциями (создание фона элитарности)
* На собеседовании спрашивается уровень дохода на прошлом месте — манипуляция эмоциями (если кандидат подходит, то можно предложить всего на 5-10% больше)
* С вами хочет поговорить наш генеральный директор — манипуляция эмоциями
* Наш самы главный вождь занят переговорами с очень крупной компанией, он с вами поговорит только через неделю — манипуляция эмоциями
И вот вопрос возникает: в чем разница между временем и энергией? Стоит ли их делить? В чем от этого профит?
Прискорбно, что тезисы на отдельной странице, не все будут читать много букв. Потому попсовые слова в названиях докладов будут решать. А в целом спасибо за инициативу, я вот на работе уже несколько человек уговорил пойти :)
Мне кажется в консерватории есть проблема. Исходный код это очень личная штука, и тащить туда всякую гадость, да еще транзитивно, это рак мозга.
Каждый раз, когда добавляется новая зависимость, надо думать, что она принесет в проект. К слову сказать, не все транзитивные зависимости нужны в проекте.
К сожалению, люди разрабатывающие библиотеки и выкладывающие их в репозитории, сами имеют грешок с каками в зависимостях. Я уж молчу про обычные проекты, которые их используют. Задолбался на каждом новом проекте вычищать бардак.
В итоге побойтесь бога, не добавляете бездумно всякую каку и фигачьте побольше эксклудов. Серебряной пули нет.
4. Делаю кошерный работающий скрипт и использую БД postgresql где есть транзакции в DDL — wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis
5. Согласен идея с путями не очень, я бы предпочел внутренние идентификаторы ченджсетов. А чексуммы это отдельный ад, нафиг их.
Дополнения:
1. Вы до сих пор верите в волшебные свойства библиотек? У вас всегда работает правильно конвертация xml в sql скрипт? Вам не надо на горячую писать упдейты, а потом вписывать их в ченджсеты? Опять я вам завидую :)
4. Я так и не дошел реального использования флайдб. Вроде бы у них роллбеков не было, и это немного печалило. Хотя есть надежда что там код и реализация, не такое гавно как в ликвидбейзе.
Итак:
1. Порядок в именовании файлов с ченджсетами это очень хорошо, как в прочем любой порядок. Возможно в имени ченджсета стоит отражать тип БД для которого он писан.
2. Ролбеки для ченджсетов это полезно и клево, но не стоит забывать, что надо вручную тестировать выполнения ченджсета и его откат, это обязательно!
3. В целом маленькие ченджсеты это опять про порядок в их структуре. Но есть нюансы, о них ниже.
4. Вам действительно не жаль своего времени для каждой сущности писать ченджсет? Я вам не завидую!
5. Я предпочитаю помещать ченджсеты в класспатх, и брать их относительно корня класспатх. Тога мы перестаем зависеть от операционных систем и других странностей.
6. Менять прошлое не всегда хорошая идея. В большинстве случаев надо делать отдельный ченджсет. Но тут не все так просто.
7. Согласен хранить данные в ченджсетах не очень разумная идея. Они приводят к увеличению объема ченджсетов, ну и не стоит забывать что миграции ведь для них тоже придется писать.
8. Пункт тоже логичен. Никому верить нельзя.
9. Я бы дополнил пункт, и сказал что XML ченджсеты зло, возможно хуже чем DSL. И SQL тут самое то. Удобно, быстро, прозрачно.
10. Опыт конечно хорошо, но вы бы видели исходный код liquibase. Например логер туда впилить весело :)
И в дополнении:
1. Может быть xml описание зло? Вас действительно не напрягает это писать и поддерживать? Просто я сторонник обычного нативного sql.
2. Иногда полезно делать ченджсет со всей структурой БД, куча маленьких на новой БД применяется не быстро порой. И опять я намекаю на sql ченджсеты тут.
3. Чем больше размер sql ченджсета, тем дольше считается контрольная сумма. Это еще одна из причин почему хранить данные в ченджсетах зло. Помню мегабайт текста обрабатывался за секунд 20.
4. Есть аналоги, и надо думать и пробовать что лучше. Например flyway — flywaydb.org/ (там есть таблица сравнения на подумать).
Часто учат других чтобы самому понять тему. Но тут главное не скатится в самоуслаждения себя что приведенная точка зрения это истина. Потому не стоит искать причины, надо искать конкретную одну причину для конкретного человека.
Я вот думаю что истинная причина прокрастинации в том, что мы пытаемся следовать своеобразной моде. В итоге то что мы хотим делать, на самом деле хотят другие. Открытость и прозрачность современного общества способствуют этому. И мы упорно продолжаем жрать кактус и заставляем себя делать всякую хрень.
«И что человечество попросило тебя на этот раз? Вселенную! Хм, Надеюсь когда нибудь они созреют, и захотят не какую нибудь ерунду! » Вольный пересказ одного рассказа Харлана Эллисона.
Забавные у вас цифры. Я вот живу в Иркутске, что 5000 км от Москвы. У нас средняя зарплата программистов 35 тысяч рублей, и найти не могут! Кстати, по региону средняя зарплата обычных людей всего 25 тысяч. Когда я уходил с прошлого места работы (программист в медицинском учреждении), мне предлагали 60 тысяч на руки! И это кстати не предел для прожигателей жизни на внутреннем рынке, можно увеличить еще на 30-50 процентов :)
Так что незачет по цифрам вам :) Хотя фриланс это порой круто, мой друг получает 5600$ (170 тысяч рублей) в месяц, плюс премии всякие. Но он нашел компанию, большинство фрилансеров живут на 2-3 тысячах долларов (60-90 тысяч рублей) в месяц.
«Сколько позволит выиграть ваше решение в процентах от бюджета на поддержку медицины?» — по мне так это правильно, проводить полный анализ ситуации. Но глубоко внутри я за создание рабочих мест и покупки принтеров долгосрочной эксплуатации.
«Перфекционизм сам по себе вредная штука» — это мой взгляд на мир, и я его никогда не скрывал. И меня за это никто не уволил. Даже работая в ИДЦ.
p/s
В том бложике у меня цель пнуть айтишников и задуматься о жизни. Возможно стоит написать о вашей ситуации. Но я не могу быть полностью на вашей стороне.
И еще мысль вдогонку. Если взять не одноразовые принтеры, то появятся затраты на обслуживании. Возможно даже первое время это будет соизмеримо с одноразовыми устройствами. Но зато появится дополнительные рабочие места и налоговые отчисления в регион. Хотя оно надо? Людьми управлять это всегда дополнительные затраты и головная боль. А люди в иркутском руководстве привыкли жить одним днем, до перевода в Москву.
Вы молодец. Хотя не один вы боретесь с системой в Иркутске. В Иркутском областном клиническом-консультативно-диагностическом центре активно используют kyocera. Можете с ними связаться и они поделятся головной болью, хотя скорее всего вы и так знакомы. И кстати они посчитали что kyocera выгоднее чем hp.
Но стоит отметить, что геморроя с этим не меньше. Мало просто купить технику, надо еще покупать правильные расходные материалы (с неправильными гарантия идет лесом). Хотя вы наверное и тут в курсе, что на аукционах постоянно пытаются протолкнуть китайское гавно по цене близкой к оригинальным запчастям и картриджам. По всей стране судятся люди, но многие просто опускают руки и соглашаются на гавно. Ибо судится долго, дорого и муторно.
Вот и получается что порой проще покупать одноразовые принтеры, чем огребать на перфекционизме и чувстве справедливости. А свои силы направить в более важном/интересном направлении. Хотя вы молодец.
Есть еще одна причина опозданий: чтобы получить заказ продавец с руководителем занизили сроки на реализацию. И благодаря этому получили деньги и бонусы для себя. И тут особо ничего не сделаешь.
1. Кстати, а у вас есть данные сколько времени в среднем отрабатывает запрос на получение данных из хранилища? И среднее время обработки запроса при попадании в кэш? Просто мне довольно интересна тема оптимального выбора количества потоков. Может быть вы посоветуете почитать что-нибудь на эту тему?
2. Возможно для оптимизации можно реализовать свою стратегию ReadWriteLock с группировкой писателей в кэш (с некоторым таймаутом для писателей в кэш). Например при накоплении 5-10 писателей запрещать write и отрабатывать пакетную запись в кэш. При этом можно сэкономить на числе перестановок (переупорядочивания) в для ключей.
4. Согласен, вам не особо требуются дополнительные плюшки внешних хранилищ. К примеру, в очень крайнем случае вы кэш пересоберете заново. Распределенность кэширования скорее всего ухудшит производительность.
Итак много букв:
1. Вы так активно бросились оптимизировать под процессор, что стало интересно: как ваши оптимизации сочетаются с тем что у вас всего 16 железных обработчиков потоков (без HT 8 штук)? Просто вы упомянули что у вас 100 потоков, и любопытно понять как они вмещаются в 16 исполнителей? Переключения вас не страшат или много потоков в ожидании висят?
2. Можно предположить что есть четыре базовых стратегии для ReadWriteLock: справедливая (по времени прихода) без разделения на read/write, приоритет на read, приоритет на write, случайная. Судя по вашим заявлениям у вас обычная справедливая стратегия. Почему так? Вы проверяли другие варианты? Может быть приоритет на read повысит производительность?
3. Судя по всему у вас у каждой картинки есть уникальный числовой key. Вы его генератором фигачите? Просто меня смутила немного функция определения сегмента. Она или слишком простая, или вы для упрощения не стали приводить полную функцию. К примеру можно придти к выводу что возможно у вас перекос по нагрузке на сегменты, а часть сегментов занимает память и не используется (не исключаю что на ваших объемах таких проблем нет, но вдруг). У вас накапливается статистика по оптимальности функции определения сегмента по ключу?
4. Еще был вопрос почему вы не используете inmemory базы данных? Было бы довольно любопытно сравнение их с вашим решением. Например почему бы не взять какое нибудь nosql решение? Также из-за предвзятости разработчиков решения, я бы доверил настройку других решений для сравнения, другим людям (которые специалисты в них). Надеюсь вы поступили именно так, а то так эти цифры только для улучшения самолюбия ваших инженеров.
Я тут подумал, собеседование в компанию это ведь тоже манипуляция:
* Просят заполнить резюме по своей форме — трата времени и энергии
* Просят сделать тестовое задание — трата времени и энергии
* Просят несколько раз приехать в офис — трата времени и энергии
* Обещают премии квартальные/годовые/проектные если будешь хорошо работать — обещание денег без конкретики
* Ожидание собеседующих или заполнение опросника — трата времени и энергии
* Обещание повышения зарплаты/должности после испытательного — обещание денег без конкретики
* Рассказ о лидере рынка и крупных заказчиках — манипуляция эмоциями
* Очень умные вопросы из книжек и троллинг от собеседующих — манипуляция эмоциями
* Компания сообщает ответ не сразу — манипуляция эмоциями
* Компания не отвечает неподходящим кандидатам или отвечает через месяц-два — манипуляция эмоциями (создание фона элитарности)
* На собеседовании спрашивается уровень дохода на прошлом месте — манипуляция эмоциями (если кандидат подходит, то можно предложить всего на 5-10% больше)
* С вами хочет поговорить наш генеральный директор — манипуляция эмоциями
* Наш самы главный вождь занят переговорами с очень крупной компанией, он с вами поговорит только через неделю — манипуляция эмоциями
И вот вопрос возникает: в чем разница между временем и энергией? Стоит ли их делить? В чем от этого профит?
p/s
А продаете вы субботу презабавно, вот только у детей и жены отпрошусь :)
Каждый раз, когда добавляется новая зависимость, надо думать, что она принесет в проект. К слову сказать, не все транзитивные зависимости нужны в проекте.
К сожалению, люди разрабатывающие библиотеки и выкладывающие их в репозитории, сами имеют грешок с каками в зависимостях. Я уж молчу про обычные проекты, которые их используют. Задолбался на каждом новом проекте вычищать бардак.
В итоге побойтесь бога, не добавляете бездумно всякую каку и фигачьте побольше эксклудов. Серебряной пули нет.
5. Согласен идея с путями не очень, я бы предпочел внутренние идентификаторы ченджсетов. А чексуммы это отдельный ад, нафиг их.
Дополнения:
1. Вы до сих пор верите в волшебные свойства библиотек? У вас всегда работает правильно конвертация xml в sql скрипт? Вам не надо на горячую писать упдейты, а потом вписывать их в ченджсеты? Опять я вам завидую :)
4. Я так и не дошел реального использования флайдб. Вроде бы у них роллбеков не было, и это немного печалило. Хотя есть надежда что там код и реализация, не такое гавно как в ликвидбейзе.
Итак:
1. Порядок в именовании файлов с ченджсетами это очень хорошо, как в прочем любой порядок. Возможно в имени ченджсета стоит отражать тип БД для которого он писан.
2. Ролбеки для ченджсетов это полезно и клево, но не стоит забывать, что надо вручную тестировать выполнения ченджсета и его откат, это обязательно!
3. В целом маленькие ченджсеты это опять про порядок в их структуре. Но есть нюансы, о них ниже.
4. Вам действительно не жаль своего времени для каждой сущности писать ченджсет? Я вам не завидую!
5. Я предпочитаю помещать ченджсеты в класспатх, и брать их относительно корня класспатх. Тога мы перестаем зависеть от операционных систем и других странностей.
6. Менять прошлое не всегда хорошая идея. В большинстве случаев надо делать отдельный ченджсет. Но тут не все так просто.
7. Согласен хранить данные в ченджсетах не очень разумная идея. Они приводят к увеличению объема ченджсетов, ну и не стоит забывать что миграции ведь для них тоже придется писать.
8. Пункт тоже логичен. Никому верить нельзя.
9. Я бы дополнил пункт, и сказал что XML ченджсеты зло, возможно хуже чем DSL. И SQL тут самое то. Удобно, быстро, прозрачно.
10. Опыт конечно хорошо, но вы бы видели исходный код liquibase. Например логер туда впилить весело :)
И в дополнении:
1. Может быть xml описание зло? Вас действительно не напрягает это писать и поддерживать? Просто я сторонник обычного нативного sql.
2. Иногда полезно делать ченджсет со всей структурой БД, куча маленьких на новой БД применяется не быстро порой. И опять я намекаю на sql ченджсеты тут.
3. Чем больше размер sql ченджсета, тем дольше считается контрольная сумма. Это еще одна из причин почему хранить данные в ченджсетах зло. Помню мегабайт текста обрабатывался за секунд 20.
4. Есть аналоги, и надо думать и пробовать что лучше. Например flyway — flywaydb.org/ (там есть таблица сравнения на подумать).
Я вот думаю что истинная причина прокрастинации в том, что мы пытаемся следовать своеобразной моде. В итоге то что мы хотим делать, на самом деле хотят другие. Открытость и прозрачность современного общества способствуют этому. И мы упорно продолжаем жрать кактус и заставляем себя делать всякую хрень.
«И что человечество попросило тебя на этот раз? Вселенную! Хм, Надеюсь когда нибудь они созреют, и захотят не какую нибудь ерунду! » Вольный пересказ одного рассказа Харлана Эллисона.
Так что незачет по цифрам вам :) Хотя фриланс это порой круто, мой друг получает 5600$ (170 тысяч рублей) в месяц, плюс премии всякие. Но он нашел компанию, большинство фрилансеров живут на 2-3 тысячах долларов (60-90 тысяч рублей) в месяц.
«Перфекционизм сам по себе вредная штука» — это мой взгляд на мир, и я его никогда не скрывал.
И меня за это никто не уволил.Даже работая в ИДЦ.p/s
В том бложике у меня цель пнуть айтишников и задуматься о жизни. Возможно стоит написать о вашей ситуации. Но я не могу быть полностью на вашей стороне.
Вот давайте на примере принтеров. Сколько позволит выиграть ваше решение в процентах от бюджета на поддержку медицины?
p/s
Эти рассуждения верны, только если там нет откатов конечно. в случае откатов они неправы конечно. Но тут надо писать в прокуратуру.
Но стоит отметить, что геморроя с этим не меньше. Мало просто купить технику, надо еще покупать правильные расходные материалы (с неправильными гарантия идет лесом). Хотя вы наверное и тут в курсе, что на аукционах постоянно пытаются протолкнуть китайское гавно по цене близкой к оригинальным запчастям и картриджам. По всей стране судятся люди, но многие просто опускают руки и соглашаются на гавно. Ибо судится долго, дорого и муторно.
Вот и получается что порой проще покупать одноразовые принтеры, чем огребать на перфекционизме и чувстве справедливости. А свои силы направить в более важном/интересном направлении. Хотя вы молодец.
2. Возможно для оптимизации можно реализовать свою стратегию ReadWriteLock с группировкой писателей в кэш (с некоторым таймаутом для писателей в кэш). Например при накоплении 5-10 писателей запрещать write и отрабатывать пакетную запись в кэш. При этом можно сэкономить на числе перестановок (переупорядочивания) в для ключей.
4. Согласен, вам не особо требуются дополнительные плюшки внешних хранилищ. К примеру, в очень крайнем случае вы кэш пересоберете заново. Распределенность кэширования скорее всего ухудшит производительность.
1. Вы так активно бросились оптимизировать под процессор, что стало интересно: как ваши оптимизации сочетаются с тем что у вас всего 16 железных обработчиков потоков (без HT 8 штук)? Просто вы упомянули что у вас 100 потоков, и любопытно понять как они вмещаются в 16 исполнителей? Переключения вас не страшат или много потоков в ожидании висят?
2. Можно предположить что есть четыре базовых стратегии для ReadWriteLock: справедливая (по времени прихода) без разделения на read/write, приоритет на read, приоритет на write, случайная. Судя по вашим заявлениям у вас обычная справедливая стратегия. Почему так? Вы проверяли другие варианты? Может быть приоритет на read повысит производительность?
3. Судя по всему у вас у каждой картинки есть уникальный числовой key. Вы его генератором фигачите? Просто меня смутила немного функция определения сегмента. Она или слишком простая, или вы для упрощения не стали приводить полную функцию. К примеру можно придти к выводу что возможно у вас перекос по нагрузке на сегменты, а часть сегментов занимает память и не используется (не исключаю что на ваших объемах таких проблем нет, но вдруг). У вас накапливается статистика по оптимальности функции определения сегмента по ключу?
4. Еще был вопрос почему вы не используете inmemory базы данных? Было бы довольно любопытно сравнение их с вашим решением. Например почему бы не взять какое нибудь nosql решение? Также из-за предвзятости разработчиков решения, я бы доверил настройку других решений для сравнения, другим людям (которые специалисты в них). Надеюсь вы поступили именно так, а то так эти цифры только для улучшения самолюбия ваших инженеров.
В целом спасибо за обзор. Было любопытно читать.