• Как оценить квалификацию программиста в рамках конкурса чтобы не нарушить 223-ФЗ?

    kumaxim
    @kumaxim
    Web-программист
    Берете из своей системы кусок кода. Код должен быть либо с "запахом"(см. "Чистый код" Роберт Р. Мартин) либо не в полном объеме решать Вашу задачу.

    Пускай у нас будет какой-то модуль системы, который должен одновременно обрабатывать 1 млн. запросов от юзеров. Когда этот модуль изначально писался, рассчитывали на 100 тыс, и на этой отметке он отрабатывает за 2,3 сек, однако, с ростом нагрузки время его работы стало более 30 секунд.
    Задача и критерий оценки - переработать этот кусок кода так, чтобы на 1,5 млн запросов от юзеров этот код отрабатывал за минимальное время, которое ниже чем текущее.

    При обращении любого из участников в ФАС, Вы сможете достать кусок кода того исполнителя, с которым Вы подписали контракт и показать и проверяющим и обиженному участнику, что его решение не является лучшим из тех, которые были получены в результате проведения тендера, чем и обусловлено Ваше решение не в его пользу.

    Предвижу вопрос, а что делать если результаты всех участников приблизительно одинаковы(диапазон разброса не более 10%)? Для этого в своей оценочной задаче Вы должны предусмотреть второй/третий/четвертый и т.д. критерии оценки.

    Ставьте вменяемый количественный показатель, который можно измерить: время исполнения при заданной нагрузке, количество строк кода, набор используемых технологий, опыт членов команды и т.п.
    Ответ написан
    2 комментария
  • Состав документации корпоративного портала?

    Начните с гост 34, гост 2.601
    Там не много, но дадут понимание что вообще нужно иметь из документации в целом.
    Ответ написан
    4 комментария
  • Порекомендуйте обучающие сайты по wordpress?

    VoxelGod
    @VoxelGod
    Настройка шаблонов WordPress
    Ответ написан
    Комментировать
  • Как вы делаете дизайн сайта?

    paulradzkov
    @paulradzkov
    Дизайнер, верстальщик, начальник отдела UI
    1. На первой встрече обычно удается узнать только область деятельности и смутные очертания того, как представляет себе результат заказчик. Обычно заказчик показывает пару сайтов из своей отрасли, которые ему нравятся. Мы с ним можем совместно на бумаге сделать пару эскизов и составить список «того, что должно быть на сайте».

    2. Минимальный достаточный результат — сделать лучше, чем у конкурентов. Поэтому вторым пунктом изучаю сайты из этой отрасли, делаю скриншоты, запоминаю хорошие решения, чтобы повторить, и плохие решения, чтобы избегать. На этом этапе обычно узнаешь много нового про отрасль и появляется куча вопросов к заказчику, которые просто не могли прийти в голову на первой встрече.

    3. Дальше нужно узнать ответы на вопросы из пункта 2 и тогда можно оценить сроки и стоимость.

    4. Начинаю рисовать wireframes. В графическом редакторе (у меня Sketch) создаю новый документ, размечаю в нем модульную сетку и начинаю накидывать туда контент.

    На этом этапе у меня только белый фон, черный текст шрифтом по-умолчанию (Open Sans) и 2-3 оттенка серого для кнопочек, линеечек и плашечек. Никакого дизайна, но строго соблюдается модульная сетка. Контент использую только реальный (который дал клиент) или выдуманный (тексты с чужих сайтов, которые могли бы подойти к этому сайту, или придумываю текст сам), но ни в коем случае не «lorem ipsum» и не абстрактный текст ни о чем. Так как я делаю конкретный сайт на заданную тему, а не шаблон, то важно чтобы тексты были по-существу, и «рыба» тут будет мешать: если нечего написать, надо делать дизайн учитывая, что текста очень мало; если есть много текста, надо дробить его на подзаголовки, разбавлять врезками и иллюстрациями. Часть выдуманного текста потом перепишется в реальный, с использованием фактов о клиенте, остальное уберется за ненадобностью.

    5. Заливаю нарисованные страницы в invision, ставлю между страницами ссылки, ставлю комментарии, как это должно работать. Там, где контент придуман, заметка о том, что нужно переписать текст в таком же ключе. Где использована чужая иллюстрация, комментарий «заменить на настоящую» и т.д. Wireframes готовы.

    6. Заказчик видит более оформленный вариант, у него появляются конкретные комментарии, правки по текстам и фактам. Еще одна-две итерации и вайрфреймы превращаются в согласованное ТЗ — кликабельный прототип с реальными контентом.

    7. Начинаю раскрашивать вайрфреймы. Первая страница — «О компании». На ней обычно есть несколько абзацев текста, пару заголовков. Сначала шрифты: выбираю основной шрифт, размер, межстрочное расстояние. Font-family выбираю только из бесплатных шрифтов, иначе это может вылиться для заказчика в дополнительные затраты.

    8. На основе страницы «О компании» создаю отдельную страницу с типографикой и доделываю все остальные текстовые стили: заголовки, основной текст, lead-text, small-text, текст в таблице, списки, цитаты и отзывы, врезки, состояния ссылок в тексте, — всё, что встречалось в вайрфреймах. Позже на эту страницу будут добавляться состояния кнопок, полей ввода, табов и других интерфейсных элементов. Из элементов этой страницы создаю динамические стили, которые потом применяю ко всем остальным частям вайрфрейма.

    Кроме того, на странице с типографикой отмечаю расстояния (margins) между элементами: между заголовками и текстом, между секциями контента. Это помогает не только верстальщику, но и мне самому. Шпаргалка по расстояниям помогает придерживаться общего стиля на всех страницах, и верстальщику потом не надо ломать голову: это ошибка дизайнера или надо прописать исключение. Пример такой странички

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

    10. Отрисовываю все остальные элементы. Вайрфреймы плавно превращаются в финальный дизайн.

    11. Если в проекте много иконок, то делаю сборную страницу для иконок, а сами иконки символами вставляю на все остальные страницы.

    12. Заливаю в invision, жду комментов от заказчика, вношу правки.

    13. Если правок больше нет, создаю слайсы для экспорта картинок, иконок и т.д. Опять навожу порядок в слоях и группах. Invision автоматически экспортирует все слайсы в папку assets. Ресурсы экспортирую в обычно в @1x, @2X и svg.

    14. Если верстальщик на Винде, заливаю исходник в https://zeplin.io/ — там можно через браузер посмотреть параметры шрифтов, размеры и расстояния между элементами.

    --

    Всё это идеальный алгоритм. На практике некоторые шаги отсутствуют, некоторые меняются местами или идут параллельно. Так как я часто сам верстаю свои дизайны, то порядок в слоях не навожу, экспорт делаю по мере верстки, а иногда вообще не дорисовываю дизайн — когда идея полностью оформилась в голове, быстрее сверстать и додизайнить в браузере, чем нарисовать и сверстать.
    Ответ написан
    2 комментария
  • Что такое agile разработка?

    saboteur_kiev
    @saboteur_kiev Куратор тега Организация работы
    software engineer
    Методика разработки.

    Waterfall: все тщательно планируем, назначаем сроки, разрабатываем, сдаем.

    Agile: Примерно планируем, анализируем, назначаем конечный срок, планируем на текущую итерацию, разрабатываем, планируем на текущую итерацию, разрабатываем... , сдаем

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

    Проблемы Agile:
    Люди должны быть достаточно зрелые, чтобы нормально загружать себя работой - Agile в бюрократической среде просто провалится.

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

    Agile это не сверхфича, это инструмент, точнее подход к планированию работы, но им нужно уметь пользоваться.
    Ответ написан
    Комментировать