Как стать автором
Обновить
103
0
Денис Чмель @denver

Пользователь

Отправить сообщение

Классический тест Кутейщиковой проходит, не выгорает. Выходит это вовсе не робот и мы столкнулись с типичными представителями стрекозоида человекообразного, а они непобедимы!

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

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

Получается так. Но если совсем избегать наследования то не получится делать полиморфизм. Впрочем нет, получится при желании, но будет выглядеть как «без сахарочка». Плюс при композиции придется деинкапсулировать все protected в public, то есть открыть больше чем при наследовании. То есть страдают все киты ООП. Может тогда не ООП вам нужно?

Изолировать же завраппив в Adapter pattern (или просто геттер нормальный, точнее нормализирующий) и всё красиво и солидно в твоем коде.

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

Вот это ТМ путь. Не спрашивать ЦА, а закрыться в кабинете, спорить и стараться понять. Многим было очевидно, что деление хабра было как минимум неудобным. Как и много других решений (типа заход на habr.ru (дот ру!) из США автоматом редиректит на англ хабр, с англ статьями, вот кто кому это может быть удобно?)

Ну и что там было/есть?

Гайз. Вы оба правы. As long as коммит всегда делает код лучше (и не делает хуже) — он «годный», не важно мелкий или большой. Если доказано что он улучшает и не ухудшает (с помощью ревью, мануальных и автотестов), и, особенно, в случаях когда внутри куча «регрессивных» коммитов (типа part1, refactor, fix tests, part2 etc) часто имеет смысл сквошнуть все в 10к-строчный коммит (его потом и ревертнуть легче, если что не так). Промежуточные же нестабильные снэпшоты часто не несут смысла отдельно от всей кучи (мало чинят, больше ломают). Или скажем иначе: ими вряд ли найдешь проблему с git bisect. Откатишься на него чтоб проверить, а там краш на краше.

Другое дело если они все «годные», тогда можно и не сквошить, но надо конечно иметь достаточно покрытия чтоб писать так красиво :)
А почему бы вообще не перейти на git? Ветки там логичнее чем локальное клонирование (поэтому hg и сделали потом Bookmarks экстеншн, почти так же как у гита). Вроде единственный недостаток у гита с бранчами — он не сохранит имя бранчи для коммитов после мержа (правда предложит в коммит-месседж добавить). И да, у гита местами стремные комманды, но есть же возможноть добавить алиасы. Чтобы привычнее были комманды — добавьте алиасов (пример) чтоб были и git up и git rollback и почти всё что хочешь.
Легко переносимый? Я помню .cvs папочки были по всем подпапочкам проекта (впрочем как и .svn потом), а толку с них было ноль, так как история в них-то как раз и не хранилась (впрочем как и в .svn потом). Да и плюс еще сервер настраивать для проекта (впрочем как и в svn потом)… Вот то ли дело git init (или hg init) в папке myproject сделать, и эту же всю папку потом и забэкапить (унести конкурентам) прям со всей историей — это так сложно что ли?)
Лучше б автокомплит уже починили, на код c БД запросами без слез и кучи собственных /** var… */ не взглянешь:

    public function scopeUpcoming($query)
    {
        /** @var $query \Illuminate\Database\Query\Builder */
        return $query->where('start_date', '<=', Carbon::now())->where(function ($query) {
            /** @var $query \Illuminate\Database\Query\Builder */
            $query->where('end_date', '>=', Carbon::now())->orWhere(function ($query) {
                /** @var $query \Illuminate\Database\Query\Builder */
                $query->whereNull('end_date');
            });
        });
    }

P.S. хуже всего еще то, что $query вовсе не instanceof Illuminate\Database\Query\Builder а на самом деле Illuminate\Database\Eloquent\Builder. Но подсветка работает корректнее если указывать первое.
www.findbigmail.com — поставит лейбы типа «findbigmail->10mb» «findbigmail->5mb» на громадные письма, потом сам решаешь что с ними делать.

UPD. ой, ниже написали про «larger:5m», спасибо не знал.
Правда ли что положенные в гит файлы 100% *всегда* могут быть восстановлены?

Скажем, в 99.99% ;)

«Мусор» в git удаляется вручную запуском git gc, либо «автоматом вместе с некоторыми командами» (думаю очень специфичными), скорее всего *локально* он хранится очень долго и в git reflog можно найти все что было удалено/ребэйзнуто/аменднуто и т.п. Правда мне никогда не приходилось смотреть в reflog, если и делал push -f пару раз ошибочно то всегда находился коллега/сервер с актуальной версией. В остальном просто стараюсь делать копии веток которые собираюсь «портить».
Для меня шоком было, когда узнал, что не всегда можно откатиться в Git на то, что уже положено в репозиторий
Several ways a committer can irrevocably destroy the contents of a repository:

Ага, можно даже грохнуть все ветки, надо же какой git небезопасный :)
Однако, дышите ровнее, git хранит локально все что удалено вышеуказанными способами. Вот пример куда копать:
dchekmarev.ru/blog/article/1313679957
Не понимаю о чем вы. Цитировали про картинку с HTML оформленным CSS по-умолчанию. Автор заявляет что несложно улучшить дефолтный рендеринг добавив как минимум паддингов/отступов. Я бы еще ограничил макимальную ширину (боди по центру) и поменял шрифт/интерлиньяж. 15 минут для начинающего в CSS.
Да, кто знает. Может и наоборот, всё станет плоским, зато прозрачным ;)
Работал и на 800px и на 1600px.

Полагаю что речь про ширину. В чем проблема, сверстать c max-width?
«функциональный вид» в контексте текста это читабельный? Не пахнет челленджем тоже :)
Скорее всего, в ближайшем будущем мы увидим полу-плоские интерфейсы… с небольшими тенями, подсказывающими, что можно нажать или кликнуть.



Не согласен, и вот почему. Отказ от скевоморфизма, а в дальнейшем и от псевдо-3д — закономерность. Пользователи давно привыкли что почти всё что выделяется — кликабельно. Так же как ранее считалось ссылкой всё что подчеркнуто (что теперь тоже не обязательно). Как привыкли понимать/исследовать такие абстрактные иконки, как на картинке. Тут даже иллюстрация непоследовательна: кнопки имеют тень чтобы выглядеть нажимабельными, в то время как в левом меню ничего кликабельным не выглядит (нет теней/подчеркиваний). Так и есть, пользователи и так догадываются, что почти все слова там кликабельны, а Favorites и Devices — нет. То же и с красным/желтым/зеленым флажками — если они есть, то скорее всего что-то делают — времена нефункциональной бутафории остались в 90х.

Т.е. не вижу причин для ретроспекций в интерфейсах будущего. Через 10 лет будет всем давно известно что «тапабельным» являются все прямоугольники с глаголом и/или иконкой. Незнакомые иконки будут следовать правилу «двойного нажатия» (второй клик отменяет действие первого), либо же будут вести туда, где всегда будет иконка "<", т.е. возможность вернуться назад. Всё для того чтобы пользователь не боялся получать опыт через метод обратимых проб.

Сверх того, новомодный свайп-жест уже сделал рудиментом кнопки влево/вправо в галлереях. Он же скрыл ранее повторяющиеся кнопки управления элементами в списках (писем, чего угодно). Так что ни тени, ни кнопки порой не будет, что не помешает людям дискаверить их «по аналогии».
В правой части карточки предполагается помечать к чему какой пароль.
Я тоже увидел такой, сделал скриншот, но через 3 сек эти пометки заменились правильными английскими текстами.

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Дата рождения
Зарегистрирован
Активность