До ассемблера с оптимизацией кэшей и оптимизаций предсказаний ветвлений вы, надо полагать, ещё не добрались?
ну вообще-то до изучения исходников добрались.
Поэтому проблемы java мне не ведомы.
откуда вам знать, что не повторяете ту же ошибку и используете профайлер по максимуму его возможностей?
да и не покажет профайлер криво написанного кода. был в моей практике товарищ, который сначала делал фуллсканы справочника, а потом только выяснял а надо ли оно ему вообще было. всего лишь поставить проверку до выборки и получаем, что 90 процентов операций было в холостую. профайлер молчал как партизан у немцев)
а как вы предлагаете проверять, что человек не вызубрил названия алгоритмов, а именно понимает о чем речь? ла еще за каких-то пару часов собеседования. если вы понимаете как работает быстрая сортировка — вы ее хоть спросонья напишете.
А если умножение вернуть стандартное, быстродействие у вас ухудшается?
этого никто не станет делать. улучшения проводились массово, а не точечно.
общая идея была "будем считать каждый байт и такт".
кстати, можете взять jmh и просто поэкспериментировать. у меня выходило, что при ограничении в 64 мегабайта стандартное умножение отставало уже очень даже заметно больше величины погрешности. а есть и похуже требования.
Профайлер часто показывает, что такие системы бывают
моя практика показывает, что 9 из 10 java-программистов пытаются профилировать приложение без включения спец режима на горячем..) хорошо если они тогда хоть что-то там найдут.
посмотрите лекции Паньгина из Однокласников для примера.
да.
я просто к чему это все. я пытаюсь донести простую мысль.
алгоритмы надо знать не для галочки. их надо знать просто для того, чтобы понимать какая работа уже была проделана с максимальной эффективностью.
еще с универа придерживаюсь правила — «страшен не тот. у кого атомная бомба, а тот, кто знает где найти ее чертежи и материалы».
просто зная, что «что-то такое я уже видел» вы можете в пару минут поиска сократить время работы с недели до часов. в условиях бизнеса это очень много значит и самым благотворным образом может сказаться на карьере, освободив уйму времени для более интересного.
ничего странного. сказано же, что она типовая. но вы же не по каждой задаче идете в гугл с целью узнать нет ли готового решения? и первое предложенное с ходу решение этой простейшей задачки отправило бы систему думать о смысле бытия.
вопрос с добавлением в отсортированный список не отпадает. золотое сечение тут использовать не получится — элементы лежат в памяти не подряд.
это не HashMap и ткнуть в нужный элемент не получится. чтобы получить, скажем, 4й элемент придется обратиться к 1му, от него ко второму, от него к третьему и лишь потом получите нужное.
а теперь представим список из 1_000_000_000 элементов и вы добавили какое-то число, равное max-1… можно идти домой — сегодня результата не будет.
а если подробнее — просто рядом размещается стек с актуальным минимумом. вынимается элемент — минимум стирается и сверху оказывается новый. добавляется — создается новый элемент.
это вот действительно самая типовая задача.
И тормозит у вас, конечно, именно умножение чисел, да?
это возможно удивит, но систем, в которых виновата в тормозах только 1 операция почти нет.
но вот после чистки кода от таких вот "типовых" решений подняли производительность на треть. это кропотливая и далеко не быстрая работа.
> приходит в голову хранить поступающие значения в отсортированном связанном списке
ого! вместо единичного времени вставки в стек вот так запросто перейдем к линейному времени(место-то надо найти). и правда… где 1 такт на вставку, там и секунду подождать можно (если стек не из 100 элементов, конечно). только вот как из стека потом вынимать-то… немножко конфуз с правилом FILO выходит.
а решается это самым типовым алгоритмом с созданием дублирующего стека.
> А вы мне рассказываете про перерасход аккумулятора и расход времени на мобильнике?!
а кто сказал. что подсветка вообще будет работать? может это приложение отслеживает геопозицию и шлет на сервер как маяк, например. там вообще экран не нужен. а если подбирается телефон с максимальным временем жизни (ну вот пожадничаю я на нормальную спутниковую сигналку для авто и подброшу телефон) — будет подбираться железо с минимальным процессором.
> У меня тут сложные вычислительные задачи (да, обсчёт модели гироскопа дорогая штука. А уж если ещё и фильтр Калмана добавить...)
куда уж мне с 3 миллиардами финансовых операций в сутки 24/7 в swift-е и обязательно не в кластере… написать абы как и пусть банки в очереди ждут пока транзакция досчитается. (и такое в практике было)
а я и не говорю, что лично вы их не знаете.
но вот привожу пример зачем их нужно знать — чтобы не сливать время и деньги проекта в канализацию велосипедами.
вы же конечно знаете скажем перемножение Карацубы? замечательнейший ведь алгоритм, согласны?
В условиях ограничений по ресурсам (на мобильнике, например) кто-то малограмотный просто воспользовался бы стандартным алгоритмом из библиотеки и получил перерасход аккумулятора и расход времени.
довольно трудно использовать кусочки, когда не знаешь о них.
вот пример. у вас будет стэк и задача в любой момент времени отдать какую-то минимальную на весь стэк величину. стек то получает элементы, то теряет. и как у гугла спросить есть ли что-то такое?
я согласен, что не надо знать прямо дострочно алгоритмы. это уже перебор, но сами алгоритмы надо знать и понимать на уровне псевдокода — просто чтобы не оказалось, что вы пилили алгоритм комивояжера неделю. даже если все получилось и заработало (что несомненно является успехом) — трата времени неоправданна.
аналогична ситуация с паттернами. их придумали не просто для того, чтобы было что спрашивать у джунов на собеседовании, а чтобы экономить время.
да не обязательно пакостить)
просто достаточно не досдать дела, а когда через неделю хватятся — «я забыл. было записано в файлике. файлик стер перед уходом. жесткий диск облил бензином в пустыне Гоби, поджег и закидал пепел песком»
Про инкапсуляцию не согласен. Валидность идентификатора зависит от внутренней реализации UnitManagerа и RotateCounter, который, кстати, я и использую в нескольких местах, ничего не должен знать об ее особенностях.
напрашивается паттерн фабрики.
вы указываете тип нужного идентификатора (строка, число, UUID, полоски зебры), отдельно указывается алгоритм проверки, что идентификатор свободен.
После этого любой из кирпичиков свободно вынимается и заменяется на аналог.
Но если так уж нужно иметь средство проверки именно в UnitManager… Если так?
не вгонял в компилятор, но суть примерно такая.
хотя мы углубляемся уже в евангелистику)
SOF — это Stackoverflow. тут опять же спор вечен. я лично больше люблю работать с ребятами, которые могут решить проблему разобравшись в ней по исходникам. Доходит до обращений к исходникам Jdk. Не могу утверждать, что готовый ответ плохо. При дефиците времени это даже спасает. Но ведь потратите вы час на изучение исходников или минуту на копирование строки — что запомнится?)
Eclipse-проект нельзя просто так взять и запустить в другой IDE.
ну вообще можно. но только предварительно установить специальный плагин нужно и в 90-95 процентах случаев все заведется)
Рефлексия это получение информации о типе на этапе выполнения. А это обработка на этапе компиляции.
У вас на этапе компиляции работает программа. Пусть и процессор. Все равно процесс есть.
Но частично согласен — это скорее из сферы плагинов и т.п.
Да и те же постпроцессоры спринга на рефлексию завязаны не слабо. А уж там ребята явно очень долго думали как бы обойтись без этого. И как видно не придумали.
При анализе метода в классе, тип параметра String, а в интерфейсе — T, и все попытки получить вместо него String не к чему не привели.
о! эта задача интересна) так просто не обходится.
возможно эта статья натолкнет на решение?
RotateCounter не может знать о том, свободен ли выбранный id
эммм… а можно поинтересоваться откуда столько смелости просто выкинуть принцип инкапсуляции и размазать знания о функционале по всему проекту?
как раз класс, занимающийся идентификаторами и должен заниматься проверками их валидности.
вообще статья мне понравилась, но работать с таким я откровенно не хотел бы)
во-первых, использование SOF должно сводиться к минимуму. не потому что там легко найти ответы (чтение документации полезнее списывания), а потому что можно перетащить чужие ошибки.
во-вторых, если я возьму этот проект и запущу его в другой IDE или даже просто другом eclipse — оно работать будет? не уверен… но если будет — это потрясающе.
ну и чисто эстетическое замечание — reflection- методы являются проктологией в Java. обычно их приплетают либо если все совсем плохо(сторонняя библиотека с приватными доступами etc), либо где-то в архитектуре ошибка. с точки зрения практики — задача интересная. но для поддержки неприменимо.
Как я понимаю изначально проблема пришла из невозможности понять откуда взялся метод.
JavaDoc тогда уж в помощь. Ну или пользуйтесь горячими клавишами вроде "перейти к родителю".
/**
* {@link ru.ohotnik.lab.SomeClass#myMethod(String, String)} - ссылка на метод. в IDEA доступна для перехода по клику. другие IDE думаю не хуже
* {@link ru.ohotNik.lab.SomeClass} - ссылка на класс ...
*/
Дело в том, что я так и не смог найти способ получить фактические параметры типов которым для обобщенных интерфейсы.
небольшая опечатка. не совсем понял что не получилось.
я в алибабе забыл спросить про парковку… но зато уточнил действует ли в РФ требование уведомлять супервизора о служебных романах. ответили, что не знают о таких прецедентах в Москве)
при закрытом более года резюме… фотку сделал где-то в мае.
рынок явно более чем жив))
и это при забаненных сбертехе и люксофте. при этом я еще и стабильно отвечаю, что не интересно.
коллеги-программисты, поучитесь упорству в достижении цели у этих милых девушек-рекрутеров! =)
у меня под 200 репозиториев на bitbucket, но открыты только 4 проекта специально для резюме. не обновлял их пару лет.
и все равно почта разрывается от писем. из этого я сделал простой вывод, что хоть что-то должно быть, а уж объем не так важен.
в вакансиях на junior-позиции само понимание, что такое git и github может быть значимым фактором
просто комитить и пушить можно научиться за 10 минут. я бы скорее проверял знания что такое версионное хранение на примере любой системы (хоть svn, хоть clearcase). а то сейчас даже мидлы встречаются без знаний что такое reflog, force push, rebase. требовать такое от джуна уже скорее опция, а не обязательность.
самый простой пример. Аннотации спринга.
Ставите над методом @transactional, а в прокси-классе создается обертка вокруг вызова.
Частый вопрос на собеседовании — сработает ли такая аннотация если вызвать метод из того же класса, где он располагается. ответ — нет, так как произойдет вызов без обертки. чтобы сработал вызов нужно сделать @Autowire класса в себя и вызвать уже через поле.
package ru.incbt.cds.api.rest.function;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
/**
* @author Okhonchenko Aleksander
* @since 14.02.2018
*/
@Service
public class App {
@Autowired
private App app;
@Transactional
public void transactedMethod() {
//some work with db
}
public void someMethod() {
//вызов без обертки
transactedMethod();
//вызов с магической оберткой
app.transactedMethod();
}
}
да, большая часть клиентов бесплатники. но компания ведь деньги зарабатывает и в плюс выходит.
зарплату они сотрудникам ведь платят. хостинг оплачивают. не нищенствуют.
atlassian тоже имеет огромное количество клиентов с минимальными услугами(jira 10$ для дома) или и вовсе бесплатными(bitbucket). тем не менее недавно была статья об их доходах и стоимости в миллиарды.
годовую отчетность битрикса я не нашел — слишком много «шума» в поиске. искать долго и серьезно смысла не вижу. но в минус там я не верю.
upd ой. всего-то 19е место у компании в forbes по рунету за 2017.
допустим.
ну и пусть работают в Германии) там и клиенты более платежеспособные. а тут только жалуются как все дорого)
выполнять законодательство? да вы что! это ж дорого!
а теперь серьезно. я согласен, что российский хостинг дороже. я это ни разу не оспариваю. основной вопрос вызывает почему такая компания не провела даже поверхностную проверку партнера, от которого де-факто зависела репутация и работоспособность компании в регионе? да потому что не хотели! потому что это просто повод обойти законопроект. не удивлюсь если изначально планировалось, что будет этот коллапс и это не технический недосмотр. а именно подстава собственных клиентов чтобы снизить свои операционные расходы.
и как удачно-то упало… 2 выходных зацепило....)
ну вообще-то до изучения исходников добрались.
откуда вам знать, что не повторяете ту же ошибку и используете профайлер по максимуму его возможностей?
да и не покажет профайлер криво написанного кода. был в моей практике товарищ, который сначала делал фуллсканы справочника, а потом только выяснял а надо ли оно ему вообще было. всего лишь поставить проверку до выборки и получаем, что 90 процентов операций было в холостую. профайлер молчал как партизан у немцев)
этого никто не станет делать. улучшения проводились массово, а не точечно.
общая идея была "будем считать каждый байт и такт".
кстати, можете взять jmh и просто поэкспериментировать. у меня выходило, что при ограничении в 64 мегабайта стандартное умножение отставало уже очень даже заметно больше величины погрешности. а есть и похуже требования.
моя практика показывает, что 9 из 10 java-программистов пытаются профилировать приложение без включения спец режима на горячем..) хорошо если они тогда хоть что-то там найдут.
посмотрите лекции Паньгина из Однокласников для примера.
я просто к чему это все. я пытаюсь донести простую мысль.
алгоритмы надо знать не для галочки. их надо знать просто для того, чтобы понимать какая работа уже была проделана с максимальной эффективностью.
еще с универа придерживаюсь правила — «страшен не тот. у кого атомная бомба, а тот, кто знает где найти ее чертежи и материалы».
просто зная, что «что-то такое я уже видел» вы можете в пару минут поиска сократить время работы с недели до часов. в условиях бизнеса это очень много значит и самым благотворным образом может сказаться на карьере, освободив уйму времени для более интересного.
ничего странного. сказано же, что она типовая. но вы же не по каждой задаче идете в гугл с целью узнать нет ли готового решения? и первое предложенное с ходу решение этой простейшей задачки отправило бы систему думать о смысле бытия.
вопрос с добавлением в отсортированный список не отпадает. золотое сечение тут использовать не получится — элементы лежат в памяти не подряд.
это не HashMap и ткнуть в нужный элемент не получится. чтобы получить, скажем, 4й элемент придется обратиться к 1му, от него ко второму, от него к третьему и лишь потом получите нужное.
а теперь представим список из 1_000_000_000 элементов и вы добавили какое-то число, равное max-1… можно идти домой — сегодня результата не будет.
а если подробнее — просто рядом размещается стек с актуальным минимумом. вынимается элемент — минимум стирается и сверху оказывается новый. добавляется — создается новый элемент.
это вот действительно самая типовая задача.
это возможно удивит, но систем, в которых виновата в тормозах только 1 операция почти нет.
но вот после чистки кода от таких вот "типовых" решений подняли производительность на треть. это кропотливая и далеко не быстрая работа.
ого! вместо единичного времени вставки в стек вот так запросто перейдем к линейному времени(место-то надо найти). и правда… где 1 такт на вставку, там и секунду подождать можно (если стек не из 100 элементов, конечно). только вот как из стека потом вынимать-то… немножко конфуз с правилом FILO выходит.
а решается это самым типовым алгоритмом с созданием дублирующего стека.
> А вы мне рассказываете про перерасход аккумулятора и расход времени на мобильнике?!
а кто сказал. что подсветка вообще будет работать? может это приложение отслеживает геопозицию и шлет на сервер как маяк, например. там вообще экран не нужен. а если подбирается телефон с максимальным временем жизни (ну вот пожадничаю я на нормальную спутниковую сигналку для авто и подброшу телефон) — будет подбираться железо с минимальным процессором.
> У меня тут сложные вычислительные задачи (да, обсчёт модели гироскопа дорогая штука. А уж если ещё и фильтр Калмана добавить...)
куда уж мне с 3 миллиардами финансовых операций в сутки 24/7 в swift-е и обязательно не в кластере… написать абы как и пусть банки в очереди ждут пока транзакция досчитается. (и такое в практике было)
но вот привожу пример зачем их нужно знать — чтобы не сливать время и деньги проекта в канализацию велосипедами.
вы же конечно знаете скажем перемножение Карацубы? замечательнейший ведь алгоритм, согласны?
В условиях ограничений по ресурсам (на мобильнике, например) кто-то малограмотный просто воспользовался бы стандартным алгоритмом из библиотеки и получил перерасход аккумулятора и расход времени.
вот пример. у вас будет стэк и задача в любой момент времени отдать какую-то минимальную на весь стэк величину. стек то получает элементы, то теряет. и как у гугла спросить есть ли что-то такое?
я согласен, что не надо знать прямо дострочно алгоритмы. это уже перебор, но сами алгоритмы надо знать и понимать на уровне псевдокода — просто чтобы не оказалось, что вы пилили алгоритм комивояжера неделю. даже если все получилось и заработало (что несомненно является успехом) — трата времени неоправданна.
аналогична ситуация с паттернами. их придумали не просто для того, чтобы было что спрашивать у джунов на собеседовании, а чтобы экономить время.
просто достаточно не досдать дела, а когда через неделю хватятся — «я забыл. было записано в файлике. файлик стер перед уходом. жесткий диск облил бензином в пустыне Гоби, поджег и закидал пепел песком»
напрашивается паттерн фабрики.
вы указываете тип нужного идентификатора (строка, число, UUID, полоски зебры), отдельно указывается алгоритм проверки, что идентификатор свободен.
После этого любой из кирпичиков свободно вынимается и заменяется на аналог.
Но если так уж нужно иметь средство проверки именно в UnitManager… Если так?
не вгонял в компилятор, но суть примерно такая.
хотя мы углубляемся уже в евангелистику)
SOF — это Stackoverflow. тут опять же спор вечен. я лично больше люблю работать с ребятами, которые могут решить проблему разобравшись в ней по исходникам. Доходит до обращений к исходникам Jdk. Не могу утверждать, что готовый ответ плохо. При дефиците времени это даже спасает. Но ведь потратите вы час на изучение исходников или минуту на копирование строки — что запомнится?)
ну вообще можно. но только предварительно установить специальный плагин нужно и в 90-95 процентах случаев все заведется)
У вас на этапе компиляции работает программа. Пусть и процессор. Все равно процесс есть.
Но частично согласен — это скорее из сферы плагинов и т.п.
Да и те же постпроцессоры спринга на рефлексию завязаны не слабо. А уж там ребята явно очень долго думали как бы обойтись без этого. И как видно не придумали.
о! эта задача интересна) так просто не обходится.
возможно эта статья натолкнет на решение?
эммм… а можно поинтересоваться откуда столько смелости просто выкинуть принцип инкапсуляции и размазать знания о функционале по всему проекту?
как раз класс, занимающийся идентификаторами и должен заниматься проверками их валидности.
вообще статья мне понравилась, но работать с таким я откровенно не хотел бы)
во-первых, использование SOF должно сводиться к минимуму. не потому что там легко найти ответы (чтение документации полезнее списывания), а потому что можно перетащить чужие ошибки.
во-вторых, если я возьму этот проект и запущу его в другой IDE или даже просто другом eclipse — оно работать будет? не уверен… но если будет — это потрясающе.
ну и чисто эстетическое замечание — reflection- методы являются проктологией в Java. обычно их приплетают либо если все совсем плохо(сторонняя библиотека с приватными доступами etc), либо где-то в архитектуре ошибка. с точки зрения практики — задача интересная. но для поддержки неприменимо.
Как я понимаю изначально проблема пришла из невозможности понять откуда взялся метод.
JavaDoc тогда уж в помощь. Ну или пользуйтесь горячими клавишами вроде "перейти к родителю".
небольшая опечатка. не совсем понял что не получилось.
я в алибабе забыл спросить про парковку… но зато уточнил действует ли в РФ требование уведомлять супервизора о служебных романах. ответили, что не знают о таких прецедентах в Москве)
при закрытом более года резюме… фотку сделал где-то в мае.
рынок явно более чем жив))
и это при забаненных сбертехе и люксофте. при этом я еще и стабильно отвечаю, что не интересно.
коллеги-программисты, поучитесь упорству в достижении цели у этих милых девушек-рекрутеров! =)
у меня под 200 репозиториев на bitbucket, но открыты только 4 проекта специально для резюме. не обновлял их пару лет.
и все равно почта разрывается от писем. из этого я сделал простой вывод, что хоть что-то должно быть, а уж объем не так важен.
просто комитить и пушить можно научиться за 10 минут. я бы скорее проверял знания что такое версионное хранение на примере любой системы (хоть svn, хоть clearcase). а то сейчас даже мидлы встречаются без знаний что такое reflog, force push, rebase. требовать такое от джуна уже скорее опция, а не обязательность.
самый простой пример. Аннотации спринга.
Ставите над методом @transactional, а в прокси-классе создается обертка вокруг вызова.
Частый вопрос на собеседовании — сработает ли такая аннотация если вызвать метод из того же класса, где он располагается. ответ — нет, так как произойдет вызов без обертки. чтобы сработал вызов нужно сделать @Autowire класса в себя и вызвать уже через поле.
зарплату они сотрудникам ведь платят. хостинг оплачивают. не нищенствуют.
atlassian тоже имеет огромное количество клиентов с минимальными услугами(jira 10$ для дома) или и вовсе бесплатными(bitbucket). тем не менее недавно была статья об их доходах и стоимости в миллиарды.
годовую отчетность битрикса я не нашел — слишком много «шума» в поиске. искать долго и серьезно смысла не вижу. но в минус там я не верю.
upd ой. всего-то 19е место у компании в forbes по рунету за 2017.
ну и пусть работают в Германии) там и клиенты более платежеспособные. а тут только жалуются как все дорого)
выполнять законодательство? да вы что! это ж дорого!
а теперь серьезно. я согласен, что российский хостинг дороже. я это ни разу не оспариваю. основной вопрос вызывает почему такая компания не провела даже поверхностную проверку партнера, от которого де-факто зависела репутация и работоспособность компании в регионе? да потому что не хотели! потому что это просто повод обойти законопроект. не удивлюсь если изначально планировалось, что будет этот коллапс и это не технический недосмотр. а именно подстава собственных клиентов чтобы снизить свои операционные расходы.
и как удачно-то упало… 2 выходных зацепило....)