Аххх… TD в 2018…
Если у автора имеются статьи с более продвинутыми проектами или, например, клиент — серверные игры на Unity, с удовольствием жду подобной статьи :)
Просто отличное поле для мошенников. Сейчас из актуальных каршеринг дурят с зарегистрированными аккаунтами на левых людей, а тут что? Да всё тоже самое на первый взгляд, единственное — это камеры, но когда это останавливало людей? В общем, до России это не скоро доберется :)
Скоро людей, которые пишут на C++/C#/Java, вообще не останется.
Эммм… Сильное заявление.
Писал 2 года на Scala в Spark'e. Писал, писал, всё здорово. Начал менять работу после слов: «Зачем нам один дорогой Scala разработчик, если можно взять 2-3 Java разработчиков и научить работать со Spark?».
Смотрел конференцию когда-то давно (наверное в 2017 году) Евгения Борисова на JPoint, где как раз таки наоборот говорят о закате Scala.
Тебе нужен специалист, который шарит в необходимых технологиях и у него проекты есть, и вроде понимание как это должно работать, какие есть проблемы — экспертиза одним словом. И ты ему не даш шанс из-за того, что он на бумажке не может код написать?))
Недавно книгу одну читал, что люди очень любят производить оценку по себе. Все что тебе кажется очень легким, очевидным и простым, для другого может оказаться не так тревиально. Поэтому, если уж человек не совсем идиот и я вижу энтузиазм, желание работать и развиваться, то почему бы не дать шанс? Ааа, он же кодить на бумаге не может… Что ж, будем искать человека который может...
Тут еще одна актуальная проблема: «я знаю логику и напишу на любом языке, но изучаю их поверхностно» или «я очень сильный спец в своем языке, но всё что вокруг для меня темный лес».
Спорный момент кто из вас лучше. Для одного работодателя, как писал выше автор, твой друг бы был идеальным кандидатом. Для другого работодателя, который тестирует логическими задачами аля «Есть 2 яйца, на каком этаже разобьется» и умение справиться с поставленной задачей быстро, ты бы показал себя с более сильной стороны. Но итог один — каждый специалист (если он действительно специалист) найдет своё место под солнцем.
Какого мнения придерживаюсь я?
Гугл — это инструмент, которое может тебе дать неправильное решение. Почему? А потому что ты загуглил проблему, открыл первую же ссылку на StackOverflow и скопировал решение. Добавило ли это тебе экспертизы? Нет, а это плохо. Надо стараться разбирать те типовые проблемы, с которыми ты сталкиваешься и хотя бы поверхностно изучать внутренности языка, чтобы совсем уж лохом не казаться, когда будешь собеседоваться.
Способность к программированию — не субъективно ли это?
В последнее время заметил, что большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами. Это всякие Яндексы навязывают тенденцию того, что человек, который умеет хорошо программировать, то он должен без труда решать простецкие житейские задачи на листке.
Зато если этому дяде сказать, что надо по-быстрому написать Backend на коленке с простым Rest-методом, который будет общаться через ORM с БД и брать оттуда первую строчку, позволив ему пользоваться Гуглом, он накидает Backend за 15 минут и еще сверху расскажет, какие проблемы есть, например, в Hibernate с пагинацией и как её поправить.
Тут всё сугубо индивидуально и риск найти самозванца есть всегда. Нужно задавать правильные вопросы и смотреть по ситуации.
P.S. Задания типа reverse() или кастомный стек — это походу классика уже наверное) Я не против заданий, но это не всегда является прямым показателем знаний.
Навсегда запомнил собеседование от HR (!!!) отдела в команду разработки по Skype.
— Расскажите мне о контракте между hashCode() и equals().
— (Начинаю рассказывать чего, да как).
— Нет, вы не поняли. Расскажите как это написано в JLS.
— То что вам рассказываю это разве не то?
— Нет. В JLS описано не так.
(проехали пару вопросов)
— Расскажите про уровни изолированности в JDBC.
— (Рассказываю, провожу аналогии с MS SQL и ORACLE).
— Я что-то вас не поняла. Вы там что, гуглите?
Меня после этого просто дико бомбануло. Компания не без имени, знакомые лестно отзываются о ней, но на собеседованиях выкидывают такие вот номера — вопросы по бумажке. После этого все желание продолжать диалог просто пропало.
Проблема автора на самом деле актуальная — изначально задоминировать респондента, чтобы доказать его никчёмность. Однако, после этого они еще кидают офферы, тем самым, произведя оценку твоих знаний, выставляют ценник. Прекрасно понимаю автора, что по морали такое сильно бьет, но ты держись. Не все компании такие вокруг. Остынь и снова можно попробовать.
Практически всем, кто только начинает делать первые шаги в программировании, а конкретнее в Java, говорю изучить сервис Javarush. Понятное объяснение + практика. Что еще нужно?
P.S. С данным сервисом работал где-то в 2013-2014 году, не знаю как там сейчас все поменялось.
Философия Java — Брюс Эккель
Топовая книжка :) Мне принесла понимание Java.
Java 8. Руководство для начинающих — Герберт Шилдт.
Написано всё настолько поверхностно, что даже непонятно для кого эта статья. Начинаем c PM, заканчиваем командой разработки, которая должна всем и вся.
И такой нескромный вопрос — почему во всех методах решения нужно пинать, делить и направлять только разработчиков?
Бомбануло. Тут либо автор не смог правильно передать свою мысль, либо он действительно видит только проблемы в разработчиках.
Любой проект по разработке мобильных приложений
Придерусь, конечно, но в статье это единственное упоминание мобильной разработки, а по факту что риски, что методы можно отнести и к обычной разработке.
Обидно, что большая часть собеседований заключается не в выявлении таланта или экстраординарного мышления, а сугубо теоретических знаниях + предыдущего опыта работы для решения задач «здесь и сейчас».
В итоге получается, что если тебя и спросят: «Сколько стоит помыть все окна в Самаре?» -, то от тебя ждут услышать правильный ответ, а не глубину твоего мышления. Жаль, очень жаль.
Сколько бы кто не высказывал свои негативные мнения по поводу пиратства в киноиндустрии, для меня сама идея распространения и доставки до пользователя с точки зрения бизнеса — это просто гениально, потому что это вечная машина по заработку. На таком поле можно диктовать свои правила и в большинстве случаев, всё равно остаться в плюсе.
А пока остается предвкушать какую-то идею, которая в очередной раз разорвёт создание.
Только можно чуть менее скомканные диалоги?)
Просто читаешь начало фразы героя, потом выбиваешься из диалога на действия, а потом заново возвращаешься в него. Да, конечно может такой твой стиль, но как-то выбивает это из колеи. Есть же у тебя вставки между диалогами, чтобы описать действия, вот их и используй почаще)
Спасибо, очень интересно и, думаю, в текущих реалиях актуально)
пользуюсь Spring и частично доволен его функционалом, но пора бы попробовать что-то и свое
С этого обычно начинаются все проблемы.
Ты бы хотя бы изъяснил свою мысль: чем тебя не устраивает Spring и чего ты конкретно хочешь добиться своей реализацией. А то получается, ты просто наговнакодил и вывалил это людям. Думаешь, кому — то это нужно?
Слушай, каждый развивается по разному. Не нужно свой уровень скорости обучения проецировать на всех. Сейчас такое время, что те кто хочет учиться, за 2-3 года до Senior спокойно вырастают. Не хочешь — не учись. В чём проблема?
Если кеш у вас потухнет между 5 и 6 страницей, вы получите все описанные в статье проблемы
Если бы, да кабы.
Расскажу по секрету — можно не обновляй страницу целиком, а только блок с гридом.
Реализуй механизм обновления кэша, это не сложно. Опять же, зависит от задачи. Критично иметь тру данные в Realtime или некритично иметь расхождение в какой-то промежуток времени — это не то на чем стоит заострять внимание.
Если же вы сделаете большое время жизни кеша, то получите другую проблему
Извините, а снапшот раз в 10 секунд будет обновляться или как? Откуда я буду знать, что на данный момент смотрю на актуальные данные? Точно такая же ситуация.
Повторюсь, что уже писал раз пять. Тут всё решается просто — поговорил с бизнесом, согласовал как им нужно.Не надо париться.
Моя реализация чего? Паджинации? Так статья как раз о том, что её не надо делать.
Почитав статью и комментарии, мне кажется, что автор просто толсто троллит или это шизофрения?
Идеально было бы:
Один раз произвести поиск и где-то запомнить его результаты в виде снепшота на определённый момент времени.
Быстро выбирать данные мелкими порциями по мере необходимости.
Ну так ты же сам понимаешь в чём проблема, так зачем штамповать Снапшоты, если есть Кэширование? Дак еще потом ты выбрку делать. Кто мешает закэшировать данные на стороне сервера и спокойно через skip / take (или как традиционно offset / limit) брать порционно данные?
Пример:
public Info getInfo(
@RequestParam(value = "sort", required = false) final String sort,
@RequestParam(value = "skip") final Integer skip,
@RequestParam(value = "take") final Integer take) {
Просто никак не могу дойти до той истины, которую проповедует автор статьи. В большинстве случаев, заказчику надо чтобы просто данные были, а как там страницы съезжают или данные восполняются — уходит на голову разработчика. Тот способ, что описывал выше, легко подходит для реализации Lazy скроллов без пагинации.
Где хранить снепшоты? тут есть 2 варианта:
На сервере. Но тогда мы забиваем его кучей мусора с результатами поисков, которые со временем надо вычищать.
На клиенте. Но тогда надо сразу же передавать весь снепшот клиенту.
Тот кто читает этот пост, если ты заметил, что у тебя тормозит сайт, знай — это автор этого поста постарался.
Когда пришел в новую команду и меня попросили оптимизировать работу сайта, я просто в шоке был с того что он на фронт тянет. Наркоманы…
Поэтому прошу вас, не делайте никаких антипаттернов и всяких криворульных универсальных велосипедов. Реализация простыми и понятными способами — самый лаконичный вариант в любом деле.
P.S. Полистав статьи автора, особенно эту сделал вывод:
Здравствуйте, меня зовут Дмитрий Карловский и я… антиконформист
Человек просто не хочет соглашаться ни с чьим мнением и продвигает своё сомнительное решение, которое вам либо сервер превратит в помойку, либо клиент, как на скрине выше.
Краткий итог: Да, есть пагинация. Да, всем нужно знать какие есть проблемы. Прекратите придумывать велосипеды, уже до вас всё придумали (и это не только пагинации касается), берите, исходя от ваших потребностей, и пользуйтесь.
64 шарда по 500 гигов и заполненность на 60%. Ты только на картинку посмотрел и коммент сразу пошел писать?
Если у автора имеются статьи с более продвинутыми проектами или, например, клиент — серверные игры на Unity, с удовольствием жду подобной статьи :)
В остальном, спасибо за перевод)
Господи, как это слово только не коверкают.
Эммм… Сильное заявление.
Писал 2 года на Scala в Spark'e. Писал, писал, всё здорово. Начал менять работу после слов: «Зачем нам один дорогой Scala разработчик, если можно взять 2-3 Java разработчиков и научить работать со Spark?».
Смотрел конференцию когда-то давно (наверное в 2017 году) Евгения Борисова на JPoint, где как раз таки наоборот говорят о закате Scala.
Тебе нужен специалист, который шарит в необходимых технологиях и у него проекты есть, и вроде понимание как это должно работать, какие есть проблемы — экспертиза одним словом. И ты ему не даш шанс из-за того, что он на бумажке не может код написать?))
Недавно книгу одну читал, что люди очень любят производить оценку по себе. Все что тебе кажется очень легким, очевидным и простым, для другого может оказаться не так тревиально. Поэтому, если уж человек не совсем идиот и я вижу энтузиазм, желание работать и развиваться, то почему бы не дать шанс? Ааа, он же кодить на бумаге не может… Что ж, будем искать человека который может...
Спорный момент кто из вас лучше. Для одного работодателя, как писал выше автор, твой друг бы был идеальным кандидатом. Для другого работодателя, который тестирует логическими задачами аля «Есть 2 яйца, на каком этаже разобьется» и умение справиться с поставленной задачей быстро, ты бы показал себя с более сильной стороны. Но итог один — каждый специалист (если он действительно специалист) найдет своё место под солнцем.
Какого мнения придерживаюсь я?
Гугл — это инструмент, которое может тебе дать неправильное решение. Почему? А потому что ты загуглил проблему, открыл первую же ссылку на StackOverflow и скопировал решение. Добавило ли это тебе экспертизы? Нет, а это плохо. Надо стараться разбирать те типовые проблемы, с которыми ты сталкиваешься и хотя бы поверхностно изучать внутренности языка, чтобы совсем уж лохом не казаться, когда будешь собеседоваться.
В последнее время заметил, что большинство проходящих дядь собеседование не умеют писать код на бумажке, при том являются отличными специалистами. Это всякие Яндексы навязывают тенденцию того, что человек, который умеет хорошо программировать, то он должен без труда решать простецкие житейские задачи на листке.
Зато если этому дяде сказать, что надо по-быстрому написать Backend на коленке с простым Rest-методом, который будет общаться через ORM с БД и брать оттуда первую строчку, позволив ему пользоваться Гуглом, он накидает Backend за 15 минут и еще сверху расскажет, какие проблемы есть, например, в Hibernate с пагинацией и как её поправить.
Тут всё сугубо индивидуально и риск найти самозванца есть всегда. Нужно задавать правильные вопросы и смотреть по ситуации.
P.S. Задания типа reverse() или кастомный стек — это походу классика уже наверное) Я не против заданий, но это не всегда является прямым показателем знаний.
— Расскажите мне о контракте между hashCode() и equals().
— (Начинаю рассказывать чего, да как).
— Нет, вы не поняли. Расскажите как это написано в JLS.
— То что вам рассказываю это разве не то?
— Нет. В JLS описано не так.
(проехали пару вопросов)
— Расскажите про уровни изолированности в JDBC.
— (Рассказываю, провожу аналогии с MS SQL и ORACLE).
— Я что-то вас не поняла. Вы там что, гуглите?
Меня после этого просто дико бомбануло. Компания не без имени, знакомые лестно отзываются о ней, но на собеседованиях выкидывают такие вот номера — вопросы по бумажке. После этого все желание продолжать диалог просто пропало.
Проблема автора на самом деле актуальная — изначально задоминировать респондента, чтобы доказать его никчёмность. Однако, после этого они еще кидают офферы, тем самым, произведя оценку твоих знаний, выставляют ценник. Прекрасно понимаю автора, что по морали такое сильно бьет, но ты держись. Не все компании такие вокруг. Остынь и снова можно попробовать.
P.S. С данным сервисом работал где-то в 2013-2014 году, не знаю как там сейчас все поменялось.
Топовая книжка :) Мне принесла понимание Java.
Эта интереснее :)
И такой нескромный вопрос — почему во всех методах решения нужно пинать, делить и направлять только разработчиков?
Бомбануло. Тут либо автор не смог правильно передать свою мысль, либо он действительно видит только проблемы в разработчиках.
Придерусь, конечно, но в статье это единственное упоминание мобильной разработки, а по факту что риски, что методы можно отнести и к обычной разработке.
В итоге получается, что если тебя и спросят: «Сколько стоит помыть все окна в Самаре?» -, то от тебя ждут услышать правильный ответ, а не глубину твоего мышления. Жаль, очень жаль.
А пока остается предвкушать какую-то идею, которая в очередной раз разорвёт создание.
Просто читаешь начало фразы героя, потом выбиваешься из диалога на действия, а потом заново возвращаешься в него. Да, конечно может такой твой стиль, но как-то выбивает это из колеи. Есть же у тебя вставки между диалогами, чтобы описать действия, вот их и используй почаще)
Спасибо, очень интересно и, думаю, в текущих реалиях актуально)
С этого обычно начинаются все проблемы.
Ты бы хотя бы изъяснил свою мысль: чем тебя не устраивает Spring и чего ты конкретно хочешь добиться своей реализацией. А то получается, ты просто наговнакодил и вывалил это людям. Думаешь, кому — то это нужно?
Если бы, да кабы.
Расскажу по секрету — можно не обновляй страницу целиком, а только блок с гридом.
Реализуй механизм обновления кэша, это не сложно. Опять же, зависит от задачи. Критично иметь тру данные в Realtime или некритично иметь расхождение в какой-то промежуток времени — это не то на чем стоит заострять внимание.
Извините, а снапшот раз в 10 секунд будет обновляться или как? Откуда я буду знать, что на данный момент смотрю на актуальные данные? Точно такая же ситуация.
Повторюсь, что уже писал раз пять. Тут всё решается просто — поговорил с бизнесом, согласовал как им нужно.Не надо париться.
Почитав статью и комментарии, мне кажется, что автор просто толсто троллит или это шизофрения?
Ну так ты же сам понимаешь в чём проблема, так зачем штамповать Снапшоты, если есть Кэширование? Дак еще потом ты выбрку делать. Кто мешает закэшировать данные на стороне сервера и спокойно через skip / take (или как традиционно offset / limit) брать порционно данные?
Пример:
public Info getInfo(
@RequestParam(value = "sort", required = false) final String sort,
@RequestParam(value = "skip") final Integer skip,
@RequestParam(value = "take") final Integer take) {
Criteria criteria = Info.builder()
.range(Range.of(skip, take, Sort.by(SortUtils.getOrder(sort, Sort.Direction.ASC))))
.build();
return InfoService.find(criteria);
}
Просто никак не могу дойти до той истины, которую проповедует автор статьи. В большинстве случаев, заказчику надо чтобы просто данные были, а как там страницы съезжают или данные восполняются — уходит на голову разработчика. Тот способ, что описывал выше, легко подходит для реализации Lazy скроллов без пагинации.
Тот кто читает этот пост, если ты заметил, что у тебя тормозит сайт, знай — это автор этого поста постарался.
Когда пришел в новую команду и меня попросили оптимизировать работу сайта, я просто в шоке был с того что он на фронт тянет. Наркоманы…
Поэтому прошу вас, не делайте никаких антипаттернов и всяких криворульных универсальных велосипедов. Реализация простыми и понятными способами — самый лаконичный вариант в любом деле.
P.S. Полистав статьи автора, особенно эту сделал вывод:
Человек просто не хочет соглашаться ни с чьим мнением и продвигает своё сомнительное решение, которое вам либо сервер превратит в помойку, либо клиент, как на скрине выше.
Краткий итог: Да, есть пагинация. Да, всем нужно знать какие есть проблемы. Прекратите придумывать велосипеды, уже до вас всё придумали (и это не только пагинации касается), берите, исходя от ваших потребностей, и пользуйтесь.