Управление временем в Java приложениях

Например, кодстайлчекер?

В моем текущем проекте уже лет 5 никто руками даты не создает. Несколько десятков программистов колбасят - это пять команд, люди периодически приходят и уходят. И все хорошо.

«Это просто мой стиль кода»

Конечно для друга. Писать для машины можно только одноразовый код.

«Это просто мой стиль кода»

Очень тонко. Завидую. Как такому можно научиться? )

«Это просто мой стиль кода»

Если программист не умеет читать "по диагонали" - то и написать код, пригодный для чтения "по диагонали", он сможет разве что случайно, как бы он не уважал коллег.

Неоднократно наблюдал, как после доработки "профессионалом" код из семантически наполненного письма другу превращался в набор инструкций для машины.

Лучше просто не допускать к коду людей, которые не умеют читать. Сначала плавать научитесь, потом бассейн наполним.

В новом выпуске журнала «Русский космос» раскрыты подробности одного из вариантов РОСС

Нужно инвестировать в картошку.

У картошки есть два офигенных плюса - ее почти наверняка станет больше, а если подкараулить воров, то ее даже выкопают забесплатно.

Стоит ли тебе прочесть книгу «Идеальный программист»?

Я в состоянии потока делю всякое. Получается иногда хорошо, иногда не очень. Если вышло не очень - сразу делаю рефакторинг - и становится хорошо. Можно канеш сказать, что типа, подумай лучше и сразу сделай хорошо - но думается не всегда, как и в поток не всегда получается войти. Вопщем, едем на том, что едет прямо сейчас. ) Не говоря уже о том, что иметь херовый код и возможность его доработать очень часто лучше, чем иметь хорошее решение, но только в голове.

Забытые жемчужины отечественного игростроя. Часть 5

Порубился в Z.A.R. знатно в свое время.

Игра имела два варианта запуска, для процессоров с MMX (в посте скрины как раз от него) и для прочих. При запуске первого варианта текстуры поверхности планеты сглаживались.

А еще там у оружия была отдача. На ряде планет со слабой гравитацией можно было с помощью оружия достичь почти первой космической скорости.

Kotlin — ещё меньше копипасты с делегатами локальных переменных

Не соглашусь.

Допустим, мы зачем-то решили сами написать компонент, который генерит SQL или мапит ResultSet.

Тогда проще взять имена полей более традиционным способом, примерно так:

    data class SomeEntity(val prop1: String, val prop2: Int)

    val properties = SomeEntity::class.declaredMemberProperties

    val someEntity = SomeEntity(prop1 = "Hello", prop2 = 100500)

    properties.forEach { prop ->
        println(prop.name + " = " + prop.get(someEntity))
    }
    // ==>
    //prop1 = Hello
    //prop2 = 100500

Kotlin — ещё меньше копипасты с делегатами локальных переменных

Справедливое замечание, добавил.

Kotlin — ещё меньше копипасты с делегатами локальных переменных

Мой реальный кейс, где я впервые применил механизм, вам бы понравился.

Был у меня тест с таким сценарием:

1 - создаем N ссылок на файлы

2 - раскладываем ссылки в специальную структуру

3 - применяем команду к структуре

4 - проверяем, как структура изменилась

Свойства ссылки в рамках структуры зависит места, которое она занимает в структуре, но при этом сама ссылка никакой информации о своем месте не содержит (и не должна).

Ссылок много. Ну и в целом тест оказался не очень простой - код занял полтора экрана.

Для упрощения читаемости теста имена переменных ссылок на файлы я сделал говорящими. Но этого оказалось мало, т.к. при дебаге в дебрях тестируемого кода имена исходных переменных уже недоступны. Поэтому я продублировал имя переменной в поле ссылки вручную, а потом и придумал, как это делать автоматически.

Но это очень специфический случай, вникать в него вряд ли интересно. Поэтому я привел вырожденный пример чтоб проиллюстрировать механизм. В каких реальных случаях его стоит применять - то личное дело каждого. )

Проксируйте всё

Изолировать бизнес-слой от ввода / вывода нужно в первую очередь для уменьшения зацепления и достижения семантической чистоты.

Это имеет смысл делать в любом проекте, который пилят больше одного человека или который займет больше пары дней.

А всякие там аутентификации, профилирования, журналирования, защита от SQL инъекций и т.д. - это решается либо ситуативно (PreparedStatement), либо фреймворками / аспектами.

Как тимлиду достоверно знать срок выполнения задач, не отвлекая подчиненных

Это если б я осуждал. А я ж не. )

Как тимлиду достоверно знать срок выполнения задач, не отвлекая подчиненных

Никак. Отвлекая - тоже никак.

Собеседования без кода: почему это сработает?

Ничто так не демонстрирует способность думать и обучаться, как наличие навыков, которые могли появиться только в результате размышлений и обучения.

Собеседования без кода: почему это сработает?

Вот да.

Программист должен уметь читать и писать код (именно в таком порядке).

Читать - это не только понимать, что делает конкретное выражение, но и уметь видеть за кодом смысл, строить гипотезы, зачем это было написано, почему именно так, осознавать культурные традиции проекта.

Я не встречал не "начитанного" программиста, который бы мог писать простой код, который легко читать и поддерживать.

Читать и писать код на собеседовании можно и должно. )

Какое тестовое задание выдать джависту? Лучше просто поговорить

Быстрый оффер - это опасная штука, если нет быстрого увольнения.

Свобода добра

Модель "уличного музыканта" вполне рабочая, хоть и с оговорками.

Некоторые из персон, которым я доначу на соответствующих сервисах, имеют суммарный доход от тысячи долларов США.

Если б в мои 15 - 25 лет так было можно, я б может и в IT не подался бы никогда, может даже и в универ не стал поступать.

Пишите плохой код и не стыдитесь этого

Хороший код отличается от плохого тем, что решает больше проблем, чем создает. ) Не пишите плохой код.

Как из джуна стать сеньором и что сделать, чтобы их отличить?

Отличие в уровне ответственности, которую персонаж успешно вывозит.

Можешь принять задачу в бизнес-терминах и сделать ее без контроля со стороны старших коллег - сениор.

Зачем прыгает быстрая коричневая лиса, или Панграммы в английском языке

Моя любимая: "Чушь: гид вёз кэб цапф, юный жмот съел хрящ."