i3 7100, встроенное видео, Kubuntu 18, Firefox 63, монитор 4k. Видео 1080р60 в utube проигрывается плавно, нагрузка на процессор ~40%. 1440p60 на том же видео — тоже все плавно, загрузка процессора выше, порядка ~80%. А вот 2160p60 уже не тащит.
Жаль, что такого туториала нет для Белоруссии. И сравнения Белоруссии и Росии в плане ИП и ООО.
И еще, есть ли нюансы при открытии ИП или ООО в России гражданином Белоруссии?
А гражданину Беларуси можно участвовать? Зарегистрировался, но пришлось ввести только часть номера паспорта, т.к. в белорусском он имеет другой формат. Теперь вот думаю, пустят ли меня?
Пару месяцев назад выбирал между Stash и GitLab. По функционалу очень схожи. Нужный нам функционал есть и там и там. Мне ближе показался Stash (возможно, потому что очень нравится BitBucket), но руководство выбрало GitLab, так как он бесплатный.
Действительно, очевидные вещи. Но написано хорошо. И лишний раз напомнить об очевидных вещах не помешает.
Делегировать обязанности не научился разве что самый активный менеджер. Да и тот наверняка делегирует время от времени. А вот оставлять на себе бремя ответственности не так распространено. «Это ж Вася делал, я тут не при чем!» Заметил, что обычно именно задачи, за которые потом можно отхватить и делегируют в первую очередь. «Справится — круто, нет — я не виноват».
В Беларуси физическое лицо может открыть счет за границей после получения разрешения от главного банка страны. Есть и исключение: если вы проживаете в данный момент в другой стране, то можете открыть там счет.
Когда уже мы перестанем говорить, что А лучше Б, доказывать, что это серебряная пуля, махать флагом и зазывать всех применять только это решение? В программировании нет универсального подхода. Паттерны, методики, фреймворки — это лишь сборники советов. Но как и где их применять — зависит от задачи. Имею опыт применения STATEful подхода. И были проекты, где такой подход был выбран неоправданно и доставил кучу проблем. Были и уместные случаи использования. Аналогичный опыт использования STATEless. Давайте все же более глубоко и широко анализировать задачу и на основании этого анализа принимать решение об используемом подходе.
Согласен с автором по поводу разночтений терминологии. Это касается не только REST'а и MVC, но и вообще многих определений и подходов. Это общая проблема.
Так же согласен насчет модели. Вообще, у меня при проектировании общий подход такой: при создании каждого слоя надо задавать вопросы — какая цель существования этого слоя? что он знает? что он умеет? кого он использует? кто его использует? И между этими вопросами не должно быть противоречий.
В целом, понимаю, что скорее всего, статья была призвана «поднять» авторитет STATEful подхода, но в итоге получилась слишком холиварной.
А не кажется ли вам, что это попытка продать то, что не нужно финансистам? Они там не тупые, все понимают.
Я не навязываю никому ничего. Меня наняли делать проект, который был им нужен. И им активно пользуются. И если по каким то причинам что то отваливается — работа финансистов останавливается. Таким образом, могу однозначно заявить, что проект им нужен. Проблема в другом — проект зависит от инфраструктуры. А она прогнила. Большинство нештатных ситуаций случается по этой причине. И все это понимают (не раз обсуждалось на разных уровнях), только делать ничего не хотят.
Проблема в том, что ничего не работает. Несколько раз в неделю стабильно происходит факап. Его затыкают костылем. И это правильно. Не правильно другое — то, что глобально никто не хочет ничего менять. А костыль, поставленный сегодня, завтра, как правило, повлечет следующую проблему. Потому что количество костылей уже давно перевалило за критическую отметку.
Полностью согласен. Дополню. Оценка программистов и их работы руководством в финансовых компаниях тоже «уникальная»: важно, что бы проблемы решались быстро (и совершенно никого не интересует, как это было сделано); любая инициатива, не приносящая непосредственно деньги, игнорируется. И получается, что человек, который пишет такой дичайший бред, от которого потом страдают все смежные проекты, но при этом решает поставленные конкретно ему задачи очень быстро — уважаемый человек. А ты сидишь, разрабатываешь красивые архитектуры, пишешь красивый код — страдаешь вначале от интеграции с поделками этого уважаемого человека, а потом еще получаешь по шапке за это. А приходишь, говоришь, давайте править инфраструктуру, вводить стандарты, я даже готов за это взяться — никому не надо, зачем? «Мы на вас не зарабатываем, только тратим. Все и так работает.» И отношение к программистам в целом: мы, финансисты — патриции, а вы — чернь. Приходишь на такую работу горя желанием свернуть горы, применить весь арсенал своих знаний и весь багаж опыта, а через некоторое время превращаешься в амебу. И, как ни странно, именно амебы тут и нужны.
Простите, наболело =)
На мой взгляд, один из лучших подходов к собеседованию. Это по сути разговор двух специалистов о том, что их интересует, что волнует, чем они живут, а не попытка одного доказать, насколько он крут, а второго оправдаться, что он не дурак. Причем кандидат в любом случае в слабой позиции — чужая территория, незнакомые люди, напряжение от того, что от твоих слов зависит результат и тд. При этом просто разговор умных людей позволяет забыть обо всех негативных факторах. Ведь программисты такой народ, они больше всего на свете любят рассказывать о своих творениях понимающим людям.
В некоторых случаях, хотелось бы увидеть, как человек кодит. Но если человек уверенно рассказывает о тех задачах, которые он решал в другой компании и толково отвечает на дополнительные уточняющие вопросы, то, как правило, за его код не стоит переживать.
Как жаль, что такой подход используют очень редко. Из большого количества собеседований, которые проходил, только несколько было похожих на описанное выше. Сам всегда пытался проводить собеседования подобным образом, но обычно получал замечания от старших коллег, что надо «больше гонять по теории», «давать больше практических заданий» и все в таком духе.
import ru.open.haven.client.gui.Test.X.Y;
public class Test {
public static class X {
public static class Y {
public static String Z = "life is good";
}
public static C Y;
}
public static class C {
public static String Z = "life is pain";
}
public static void main(final String[] args) {
System.out.println(Y.Z);
}
}
Если честно, то я даже не в курсе, что пишут в трудовую, когда увольняют по причине не прохождения испытательного срока. Просто не сталкивался лично. Но, мне кажется, что увольнение по собственному желанию работодатель предлагает не только из-за своей лояльности, но и потому, что при увольнении по причине не прохождения испытательного срока работодатель должен оформить пакет документов (в том числе задания, которые испытуемый должен был выполнить в течении испытательного срока, отчеты о выполнении и тд, в том числе с подписями испытуемого). И если такой документации нет (а ее как правило нет, т.к. испытательный срок у нас мало кто проводит правильно), то такое увольнение легко можно оспорить через суд…
И еще, есть ли нюансы при открытии ИП или ООО в России гражданином Белоруссии?
Далек от проектирования UI, но я бы взял.
JavaDoc к методу javafx.application.Application.init():
Т.е. у вас все равно контекст спринга инициализируется не в потоке JavaFX UI.
Делегировать обязанности не научился разве что самый активный менеджер. Да и тот наверняка делегирует время от времени. А вот оставлять на себе бремя ответственности не так распространено. «Это ж Вася делал, я тут не при чем!» Заметил, что обычно именно задачи, за которые потом можно отхватить и делегируют в первую очередь. «Справится — круто, нет — я не виноват».
Согласен с автором по поводу разночтений терминологии. Это касается не только REST'а и MVC, но и вообще многих определений и подходов. Это общая проблема.
Так же согласен насчет модели. Вообще, у меня при проектировании общий подход такой: при создании каждого слоя надо задавать вопросы — какая цель существования этого слоя? что он знает? что он умеет? кого он использует? кто его использует? И между этими вопросами не должно быть противоречий.
В целом, понимаю, что скорее всего, статья была призвана «поднять» авторитет STATEful подхода, но в итоге получилась слишком холиварной.
Я не навязываю никому ничего. Меня наняли делать проект, который был им нужен. И им активно пользуются. И если по каким то причинам что то отваливается — работа финансистов останавливается. Таким образом, могу однозначно заявить, что проект им нужен. Проблема в другом — проект зависит от инфраструктуры. А она прогнила. Большинство нештатных ситуаций случается по этой причине. И все это понимают (не раз обсуждалось на разных уровнях), только делать ничего не хотят.
Проблема в том, что ничего не работает. Несколько раз в неделю стабильно происходит факап. Его затыкают костылем. И это правильно. Не правильно другое — то, что глобально никто не хочет ничего менять. А костыль, поставленный сегодня, завтра, как правило, повлечет следующую проблему. Потому что количество костылей уже давно перевалило за критическую отметку.
Простите, наболело =)
В некоторых случаях, хотелось бы увидеть, как человек кодит. Но если человек уверенно рассказывает о тех задачах, которые он решал в другой компании и толково отвечает на дополнительные уточняющие вопросы, то, как правило, за его код не стоит переживать.
Как жаль, что такой подход используют очень редко. Из большого количества собеседований, которые проходил, только несколько было похожих на описанное выше. Сам всегда пытался проводить собеседования подобным образом, но обычно получал замечания от старших коллег, что надо «больше гонять по теории», «давать больше практических заданий» и все в таком духе.
Выведет «life is good»