Ответы, понравившиеся пользователю Illandar

Почему многие дизайнеры делают ОГРОМНЫМИ элементы дизайна?

Михаил Проскурин @mixail_fet

Дизайнер веб-интерфейсов

Так как являюсь представителем вида животных, именуемыми дизайнерами, объясню свою точку зрения.

1. Хороший дизайнер проверит отображение своего макета на разных разрешениях экрана - это значит, что его макет будет отрисован для FullHD, HD, планшетов и телефонов.

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

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

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

Несколько удачных примеров, когда продает картинка:

Пример 1

Пример 2

Пример 3

Пример 4

Пример 5

Пример 6

Пример 7

Ответ написан более трёх лет назад

2 комментария

Как суд должен решить спор о правах на программный код при наличии сразу двух подписей в нём?

Moskus @Moskus

Наличие подписей в файле доказывает только тот факт, что оба предполагаемых автора имели доступ к файлу до определенной даты (публикации). Авторство из этих фактов не следует вообще никак, доказательство будет признано недостаточным, суд отклонит иск о признании авторства. Решение на основе случайности - вообще за гранью бреда.

Суд не занимается расследованиями и не призывает экспертов. В гражданском иске, истец выдвигает требования, собирает доказательства в свою пользу и представляет их суду. Истец в такой ситуации должен сам, или через экспертизу и свидетелей показать, что только он мог написать код, а ответчик - не мог. Если у него это не вышло, судья не будет "признавать авторами обоих", потому что это не входит в его обязанности, он только выносит решение по требованию иска. Он отклонит иск и оставит всё как есть за недостатком доказательств.

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

Ответ написан более трёх лет назад

2 комментария

Какие диаграммы нужны для полноценного документирования программного проекта?

ned4ded @ned4ded

Верстка, Фронтенд

Добрый день!

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

Теперь немного тезисно по вашей информации:
1) Диаграмма - способ представить информацию, любую диаграмму можно описать словами.
2) Диаграмма - инструмент для выявления новой информации о системе.
3) Впервые слышу про диаграмму бизнес-объектов: может это что-то крайне редкое (крайне специализированное), но с высокой долей вероятности, это вам не потребуется.
4) UML - язык, а не гайдлан по документированию ПО, сл-но в книгах с аббревиатурой UML вы не найдете нормального руководства по документированию.

Вывод из этого следующий: диаграмма используется как подкрепление к документации, как инструмент проектирования ПО (для выявления зависимостей и новых сущностей). В обоих случаях набор нотаций будет зависеть от требований, предъявляемых к таким документам.

Если вам интересно документирование ПО, то гуглите: техническая документация, техническое задание, ГОСТ 34, ГОСТ 19, SRS, хорошая статья на хабре про это.

Если вам интересно именно полноценное описание проекта, то гуглите: методологии разработки программного обеспечения, управление проектами, pmi, pmbok, agile.

Теперь пройдемся по диаграммам в зависимости от назначения. Я сейчас могу выделить несколько направлений (не претендуя на полноту):
1) уровень бизнеса (любые части системы, находящиеся вне ПО per se)
2) уровень программного обеспечения (системные модули, компоненты системы уже реализованные на уровне ПО)
3) уровень данных (структура данных, описание типов данных и т.д.)
4) уровень hardware (например, топология сети)

На уровне бизнеса обычно описываются бизнес-процессы (idf0, idf3, aris, bpmn, dfd), воркфлоу, юзкейсы, маиндмапы и проч. - это все идет сюда. На этом уровне выделяются основные процессы, выполняемые внешними относительно системы акторами, выявляются точки их взаимодействия с системой. На основе этого проектируются основные модули системы, исполняемые ими функции и их взаимодействие. Взаимодействие системы с внешней средой.

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

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

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

К сожалению, я не могу в один пост уместить весь объем знаний, полученный мной за годы обучения и практики, но надеюсь, что это направит вас в нужное направление.

ps на небольших и средних проекта я стараюсь прибегать к одной из нотаций бизнес-процессов, если требуется что-то автоматизировать (idf или bpmn), юзкейсам для выявления интеракций пользователя с приложением; для подготовки к написанию ПО - сущность-связь, иногда алгоритмы.

Ответ написан более трёх лет назад

Комментировать

Зачем нужен контейнер если php умирает?

Максим Федоров @Maksclub Куратор тега PHP

maksfedorov.ru

Пишем код, кода становится много, его нужно обслуживать и бороться со сложностью, также нужно тщательно тестировать, тк деньги и надежность пользователей
↓
Чтобы тестировать методы класса и не зависеть от реализации -- соблюдается принцип инверсии зависимостей (и некоторые другие)
↓
Инверсия зависимостей -- нужно помнить и держать зависимости к нашему классу где-то и сам конкретный сервис наполнять нужно этими зависимостями, руками делать это

накладно

try {
    echo
        (new PurchaseOrder(
            new LocalOrderStorage(
                new NullOrderStorage()
            ),
            new OrderId($inputParams['order_id'])
        ))
            ->newInvoice(
                new InvoiceNumber(
                    new Vendor(
                        new LocalVendorStorage(),
                        new VendorId($inputParams['vendor_id'])
                    ),
                    new VendorInvoiceNumber($inputParams['vendor_invoice_number']),
                    new DateTime($inputParams['date_time'])
                ),
                new VendorInvoiceNumber($inputParams['vendor_invoice_number']),
                new DateTime($inputParams['date_time']),
                new InvoiceAmount(
                    new Amount($inputParams['amount']),
                    new Currency($inputParams['currency'])
                )
            )
                ->json()
    ;
} catch (Exception $exception) {
    return
        (new ErrorResult())
            ->json($exception->getCode(), $exception->getMessage())
        ;
}

Кроме того появляется куча параметров в проекте.
↓
На помощь приходит паттерн Dependency Injection Container (Service Container), который за нас это делает и всасывает в себя эту заботу, а мы продолжаем писать код и делать это быстро, доставляя features for customers

Ответ написан более трёх лет назад

1 комментарий