Спасибо, за статью. Ты писал, о том что keycklok плохо себя ведет при большом кол-ве сессий. Подскажи, пожалуйста, какое кол-во ты имел ввиду? 5000-10000 сессий это большое кол-во?
Ну тут не добавить не убавить )) Очень сложно подобрать задачу под хеш индекс и даже подобрав ее он совсем незначительно выигрывает у b-tree но вот что делать если понадобиться упорядочить по этому полю или применить какой то оператор кроме '=' я бы трижды подумал прежде чем использовать его.
Честно говоря не совсем понимаю для чего они вообще нужны )) Мне кажется очень тяжело придумать задачу где hash индекс был бы лучше b-tree особенно если учитывать тот факт что после удаления записей кол-во корзин не уменьшается...
Спасибо за статью, не подскажите можно как то получить доступ к idle строкам? К тем которые еще не почистил вакуум? к примеру insert into user (id, name) values (1,'ivan'); update user set name = 'petr' where id =1; Можно ли как то получить доступ к строке с ivan?
Спасибо, за статью, очень интересно и полезно. Не подскажите где можно почитать на тему того как понять когда нужно докупать железо, а когда проблема с конфигом. Ну к примеру у нас в приложении 200 server session и 1К transaction per second как понять этого много для нас и мало?
Было бы здорово если бы существовала единая сервис авторизации который хранил бы в себе все идентификатора человека (пальчики, фото сетчатки, ДНК, обертона голоса....) и у него было бы публичное API. И программисты были бы счастливы и раскрываемость преступлений повысилась бы.
Мы сейчас будем писать интеграцию где вынуждены использовать Protobuf - эта статья конечно подкинула дров в топку сомнения )) Спасибо за то что поделился горьким опытом, но за что вы так с Java ? Все там хорошо со строгой типизацией )) И динамическая типизация вроде бы с 17 Java уже вполне приличная))
Спасибо за статью, вот еще очень интересно как будут обстоять дела с изменением данных. На сколько я знаю в PostgreSql - это достаточно дорогая операция. Если наши данные часто подвержены изменением наверное используя PostgreSql можно столкнутся с трудностями.
Спасибо, за статью! Вы писали, о том что String.intern() хранится в PermGen до конца жизни приложения. На сколько мне известно они там хранятся пока хотя бы один объект ссылается на них.
Спасибо за статью, но начиная ее читать, я очень хотел получить ответ на вопрос "как перестать тупить на собесах?")) Часто такое бывает, что тебе задают вопрос на который ты криво отвечаешь, а после собеса думаешь "блин, зачем я так ответил"... Тоже самое происходит с лайфкодингом. Я думаю, что раскрытие этой темы было бы очень полезно.
Мне кажется, за UX еще долго будет отвечать человек. Это такая сложная и во многом контринтуитивная штука больше базирующаяся на опыте чем на теоретических знаниях.
Спасибо, за статью бро! Оценка скилов специалистов это всегда сложная тема. Если с программистами еще можно как то разобраться то остальные ИТ специалисты это гораздо сложнее. Ознакомиться с чьей то методикой всегда интересно.
Я именно об этом и пишу. Конечно я не жду, что кандидат услышав условия задачи за пять минут даст идеальный ответ. При том что я эту задачу уже 20 раз обсуждал с другими людьми. Тут интересно послушать кандидата. Вот у Вас интересное рассуждение на эту тему. Вы обратили внимание на то что модель криво записана. Я же там написал, что важно поговорить на эту тему. Если кандидат предложит добавить ключ в таблицу автомобили, то спроси почему так ? И в этом вопросе нет подвоха просто интересно узнать почему он так предложил. Есть ли у него еще какие то варианты. К примеру создать связывающую таблицу. Если кандидат не предложил такой вариант, то я сам предложу ему такой вариант. Потому что мне интересно услышать его мнение на этот счет.
Поймите, основная мысль которую я доношу в этой статье как раз и есть в том что нельзя ожидать однозначного ответа. Я же там написал что собеседование в стиле школьного экзамена не эффективно. Сколько раз в своей работе вы обдумывая решение проблемы меняли свои идеи? Наверняка много раз и это нормально. Нельзя ожидать что на собесе человек с первой минуты даст правильный ответ. Абсолютно нормально когда на собесе кандидат предлагает кривое решение. Это не значит, что он плохой специалист ему нужно подсказать что это решение не очень хорошее и вот если он не поймет вашу подсказку тогда можно делать какие то выводы.
Это сложно объяснить. Меняется виденье проблем. Насмотренность в любом деле очень важна. Плюс когда вы же не просто решаете задачи, а изучаете алгоритмы. Попробуйте решить задачу которую я прикрепил в статье, если вы не знакомы с алгоритмами DP то вряд ли вы ее решите.
Спасибо, за статью. Очень актуально. Согласен с тем, что уход крупных игроков с рынка не самое хорошее событие. По настоящему крутой продукт рождается в условиях конкуренции. Но все же есть вероятность того что русское ПО составит конкуренцию и вынудит конкурентов совершенствовать свое ПО и мы, как конечные пользователи, будем получать хорошие программные продукты ))
Спасибо, за статью. Ты писал, о том что keycklok плохо себя ведет при большом кол-ве сессий. Подскажи, пожалуйста, какое кол-во ты имел ввиду? 5000-10000 сессий это большое кол-во?
Когда уже эти бездушные машины начнут писать код за нас, а мы будем смотреть их ПР попивая коктейли на берегу море. Надеюсь не Баренцевого ))
Очень интересная статься, спасибо. Найти бы такую же статью про postgreSql было бы здорово ))
Ну тут не добавить не убавить )) Очень сложно подобрать задачу под хеш индекс и даже подобрав ее он совсем незначительно выигрывает у b-tree но вот что делать если понадобиться упорядочить по этому полю или применить какой то оператор кроме '=' я бы трижды подумал прежде чем использовать его.
Честно говоря не совсем понимаю для чего они вообще нужны )) Мне кажется очень тяжело придумать задачу где hash индекс был бы лучше b-tree особенно если учитывать тот факт что после удаления записей кол-во корзин не уменьшается...
Спасибо за статью, не подскажите можно как то получить доступ к idle строкам? К тем которые еще не почистил вакуум? к примеру insert into user (id, name) values (1,'ivan'); update user set name = 'petr' where id =1; Можно ли как то получить доступ к строке с ivan?
Спасибо, за статью, очень интересно и полезно. Не подскажите где можно почитать на тему того как понять когда нужно докупать железо, а когда проблема с конфигом. Ну к примеру у нас в приложении 200 server session и 1К transaction per second как понять этого много для нас и мало?
Было бы здорово если бы существовала единая сервис авторизации который хранил бы в себе все идентификатора человека (пальчики, фото сетчатки, ДНК, обертона голоса....) и у него было бы публичное API. И программисты были бы счастливы и раскрываемость преступлений повысилась бы.
Еще и мою любимую Java обидел )) Она же никого не заставляет писать на ней, не нравиться не пиши ))
Мы сейчас будем писать интеграцию где вынуждены использовать Protobuf - эта статья конечно подкинула дров в топку сомнения )) Спасибо за то что поделился горьким опытом, но за что вы так с Java ? Все там хорошо со строгой типизацией )) И динамическая типизация вроде бы с 17 Java уже вполне приличная))
Спасибо за статью, вот еще очень интересно как будут обстоять дела с изменением данных. На сколько я знаю в PostgreSql - это достаточно дорогая операция. Если наши данные часто подвержены изменением наверное используя PostgreSql можно столкнутся с трудностями.
До этой статьй я боялся только mp3 файлы на бесплатных сайтах с расширением exe )) А теперь буду всего бояться ))
Спасибо, за статью! Вы писали, о том что String.intern() хранится в PermGen до конца жизни приложения. На сколько мне известно они там хранятся пока хотя бы один объект ссылается на них.
Спасибо за статью, но начиная ее читать, я очень хотел получить ответ на вопрос "как перестать тупить на собесах?")) Часто такое бывает, что тебе задают вопрос на который ты криво отвечаешь, а после собеса думаешь "блин, зачем я так ответил"... Тоже самое происходит с лайфкодингом. Я думаю, что раскрытие этой темы было бы очень полезно.
Мне кажется, за UX еще долго будет отвечать человек. Это такая сложная и во многом контринтуитивная штука больше базирующаяся на опыте чем на теоретических знаниях.
Спасибо, за статью бро! Оценка скилов специалистов это всегда сложная тема. Если с программистами еще можно как то разобраться то остальные ИТ специалисты это гораздо сложнее. Ознакомиться с чьей то методикой всегда интересно.
Я именно об этом и пишу. Конечно я не жду, что кандидат услышав условия задачи за пять минут даст идеальный ответ. При том что я эту задачу уже 20 раз обсуждал с другими людьми. Тут интересно послушать кандидата. Вот у Вас интересное рассуждение на эту тему. Вы обратили внимание на то что модель криво записана. Я же там написал, что важно поговорить на эту тему. Если кандидат предложит добавить ключ в таблицу автомобили, то спроси почему так ? И в этом вопросе нет подвоха просто интересно узнать почему он так предложил. Есть ли у него еще какие то варианты. К примеру создать связывающую таблицу. Если кандидат не предложил такой вариант, то я сам предложу ему такой вариант. Потому что мне интересно услышать его мнение на этот счет.
Поймите, основная мысль которую я доношу в этой статье как раз и есть в том что нельзя ожидать однозначного ответа. Я же там написал что собеседование в стиле школьного экзамена не эффективно. Сколько раз в своей работе вы обдумывая решение проблемы меняли свои идеи? Наверняка много раз и это нормально. Нельзя ожидать что на собесе человек с первой минуты даст правильный ответ. Абсолютно нормально когда на собесе кандидат предлагает кривое решение. Это не значит, что он плохой специалист ему нужно подсказать что это решение не очень хорошее и вот если он не поймет вашу подсказку тогда можно делать какие то выводы.
Как стереотипнентко это выглядит. Дело не в возрасте. Говнистые люди в любом поколении.
Это сложно объяснить. Меняется виденье проблем. Насмотренность в любом деле очень важна. Плюс когда вы же не просто решаете задачи, а изучаете алгоритмы. Попробуйте решить задачу которую я прикрепил в статье, если вы не знакомы с алгоритмами DP то вряд ли вы ее решите.
Спасибо, за статью. Очень актуально. Согласен с тем, что уход крупных игроков с рынка не самое хорошее событие. По настоящему крутой продукт рождается в условиях конкуренции. Но все же есть вероятность того что русское ПО составит конкуренцию и вынудит конкурентов совершенствовать свое ПО и мы, как конечные пользователи, будем получать хорошие программные продукты ))