Shockoway

Быстрое знакомство и описание Trello
• Философия Trello
○ https://netology.ru/blog/trello
• Как использовать Trello для планирования
○ interesno.co/myself/3128a1df69ba
• 12 советов для тех, кто пользуется Trello
○ www.lookatme.ru/mag/live/things/214757-trello-tips...


Расширения Сhrome для Trello
• Полезные расширения и настройки
○ https://lifehacker.ru/2016/04/12/10-dopolnenij-dly...
○ betteri.ru/post/rukovodstvo-po-produktivnoy-rabote...
○ Мои надстройки https://i.imgur.com/bHbdtiK.png
○ Для управления расширениями Хром: SimpleExtManager

○ Надстройки Google chrome (использую постоянно)
§ Boards for Trello
§ Card Colors for Trello
§ Next Step for Trello
§ Plus for Trello (тайм-трекинг, отчёты, Scrum)
§ Pro for Trello, FREE Trelo tweaks
§ Reports for Trello
§ Toggl Button: Productivity & Time Tracker
§ Trellists: Trello Lists Master
§ Trello List Wizard
§ Multiselect for Trello (платный)

○ Надстройки Google chrome (использую периодически)
§ List Highlighter for Trello
§ Slim Lists for Trello
§ Trelabels for Trello
§ Trello List Filter
§ TrelloExport
§ Ultimella, the features pack for Trello

• Система отчетов
○ https://reportsfortrello.com/
○ https://www.toggl.com/ (надо поставить расширение toggl для хром)
○ www.plusfortrello.com

• Диаграма Ганта
○ https://elegantt.com/
○ Gantt for Trello | by Placker.com

• Для автозадач:
○ https://echofortrello.com (попроще) (прекратил существование)
○ https://butlerfortrello.com (посложнее, но и функционал шире)
○ https://ifttt.com/applets/299813p-schedule-daily-o...

Список тайм-трекеров для Trello
• https://help.trello.com/article/941-time-tracking

Расширения Хром для тайминга времени Trello на основе техники Pomodoro
• Timeneye
○ Плюсы
§ Размытый фон при запуске таймера -> фокус на задаче
○ Минусы
§ Простой таймер, без помидорок
§ Автоматом не заполняет поля "проект", "задача" и т.д. Хотя мог бы брать все это из Trello
○ Итог
§ Не понравился, неудобный

• Pomello
○ Плюсы
§ Добавляет символ "помидорки" или "галочки" к каждой выполненной задаче, + число помидорок (даже дробных)
§ Очень простой и удобный
§ Плашка "овер всех окон" с обратным отсчетом
○ Минусы
§ Нет отчетов
○ Итог
§ Использую из-за символов "помидорки"

• PomodoneApp
○ Плюсы
§ Обратный отсчёт в трее
○ Есть отчеты
§ Управляет задачами в Trello: можно закрыть любую, она автоматом переместиться в "done"
§ Подцепляет теги и проект, это удобно, не надо самому ставить.
○ Минусы
§ Отчеты в Toggle удобнее
○ Итог
§ Использую, т.к. нравится обратный отсчет в трее, не так "давит", как Pomello

• Toggl
○ Плюсы
§ Можно логгировать отдельно подзадачи из чеклистов Trello
§ Очень крутые, подробные и красивые отчеты
○ Минусы
§ Автопауза не связана с Trello
§ Все управление задачами — только через web-trello
§ Не берет "теги" из Trello
○ Итог
§ Использую постоянно, т.к. нужны отчеты

Здравствуйте.
У вас Intellij Idea Community? Если так, то поддержка JavaEE технологий в ней нет. Тут у вас два варианта:
1. Купить Ultimate версию;
2. Использовать Eclipse или Netbeans.

передаем на сервер логин
сервер генерит соль и отдает клиенту
клиент солит пароль, считает хэш (sha1 например) и передает хэш
сервак со своей стороны так же солит пароль, считает хэш и смотрит совпадает или нет.

ну и ограничения на сессию.
в итоге перехват трафика дает только доступ к сессии и не раскрывает пароль.

Мартин Фаулер круто пишет обо всех паттернах. Про DI можно почитать тут. Вообще у него отличный блог. И он же автор книги P of EAA. Правда русский ее перевод крайне не рекомендую читать, можно только запутаться, так что читайте в оригинале.

Если хотите разобраться с паттернами, то самая простая (и при этом дельная!) книга - это Фриман&Фриман. Ее можно читать и на русском.

Применительно к PHP - вот лучшая книга про шаблоны (и не только), которую я видел PHP. Объекты, шаблоны и методики программирования от Мэт Зандстра.

Порядок прочтения рекомендую следующий: Фриман&Фриман, затем Мэт Зандстра, и на десерт Фаулера P of EAA.

UPD:
Важно отличать паттерн Dependency Injection от Dependency Injection Container.
Простейший пример внедрения зависимости:

interface IEngine {}
 
class V8Engine implements IEngine {}
 
class Car {
  public function __constructor(IEngine $engine) {
    $this->engine = $engine;
  }
}
 
$car = new Car(new V8Engine());

Простейший пример игнорирования явного внедрения (для такого кода трудно писать unit-тесты, его труднее понимать и править):

class V8Engine {}

class Car {
  public function __constructor() {
    $this->engine = new V8Engine();
  }
}

$car = new Car();

Отличный (и легковесный) пример DIC - это pimple:

// define some services
$container['session_storage'] = function ($c) {
    return new SessionStorage('SESSION_ID');
};

$container['session'] = function ($c) {
    return new Session($c['session_storage']);
};

Советую прочитать и понять его исходники, чтобы убедиться, что в DIC (во всяком случае для PHP) нет никакой магии. Первая версия была всего ~100 строк. Необходимо также отметить, что класс Session использует шаблон Dependency Injection, явно определяя свою зависимость от SessionStorage. А контейнер делает лишь правильную связку.

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

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

Вот очень хороший тутор по данной теме. Т.к. судя по посту вы и OpenGL не знаете.

Но вообще, без знания и опыта работы с нормальными 3D движками, браться за написание своего - это как собирать свой компьютер (покупать smd компоненты, плату, травить ее, паять все это дело и т.д.), муторно и абсолютно бестолково.

P.S. возьмите С++ и SFML и попробуйте накидай свой 2D движок. Это в разы проще и опыт какой-никакой появится. А перед тем как писать непосредственно 3D-движок, посмотрите что такое Unity и с чем его едят. На гитхабе есть самописные 3D движки, их код не мешало бы вам тоже посмотреть. А потом только браться за свой.

В том то и дело, что ваше решение не дает никаких гарантий. От слова вообще.
Статистика не дает ответов на конкретном случае.
Статистика дает ответы на на большом количестве случаев - типа, что 10% это синий, а 90% это зеленый. Но является ли синим или зеленым конкретный объект - не дает ответа ваш метод.
Ваш метод годится только как помощник, как предварительный фильтр для людей-модераторов.

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

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

Для того, чтобы можно было делать вызовы "цепочкой":
x.increment().increment().increment().print();
То есть, метод increment() возвращает тот объект, которому принадлежит.

Если бы он не возвращал this, то пришлось бы делать так:

x.increment();
x.increment();
x.increment();
x.print();

Пользуйся)

Про GitHub.

1) Любой проект, даже самый маленький начинаю в новом репозитории. Потому что:
- мало ли что из него вырастет,
- код в Гитхабе это бэкап, не засерается место в Дропбоксе или других облаках,
- мгновенный поиск по коду в репозитории, актуально когда проект уже достаточно большой,
- легче спросить совета у коллег или показать проблему, когда исходники можно посмотреть онлайн,
- проект удобно хоронить, если он заглох, или закинуть в портфолио, если он клевый.

2) Создал себе на Гитхабе две дополнительные организации внутри своего аккаунта.
- «paulradzkov-forks» — для форков чужих проектов.
- «paulradzkov-heaven» — кладбище для старых проектов, куда перемещаются все неактуальные проекты.
Эти две дополнительные организации позволяют очистить основной аккаунт от мусора. В нем теперь только несколько актуальных проектов, в которых легко ориентироваться.

3) Перемещаю все старые проекты из Дропбокса на Гитхаб в «paulradzkov-heaven». Проектов много, это долго, но освободилось уже несколько гигов (т.к. там кроме кода psd-исходники, архивы с инсталляторами и прочее). Место в облаках заканчивается, а на Гитхабе — резиновое.
Это кладбище уже пригодилось, когда у меня попросили поискать исходники проекта, над которым я работал 3 или 4 года назад, а я через минуту ответил им ссылкой на нужный репозиторий. Не пришлось никуда лезть, распаковывать, искать, запаковывать, отправлять почтой или закачивать в облако.
Повторюсь, что на Гитхабе классный поиск по исходникам: если нужно посмотреть, как что-то сделал в старом проекте, но не помнишь в каком — можно довольно быстро найти искомое без возни с архивами.

Итого.
Код должен лежать на Гитхабе.
В том числе старые проекты.
Используйте организации, чтобы рассортировать проекты, если их много.
Порядок там, где у каждой вещи есть своё место. Придумайте себе правила порядка заранее и соблюдайте их, чтобы не тратить время на ликвидацию беспорядка.