• Как организовать такую работу с диапазоном дат в JavaScript?

    @kstyle
    создать функцию. на вход дата, которая сравнивается с граничными датами сезона. попадает - возвращаем стоимость имеенно для этого сезона. в цикле перебираем даты пользователя, для каждой вызываем функцию. для работы с датами moment.js или DateTime php
    Ответ написан
    Комментировать
  • Как организовать процесс съёмки, учёт и хранение фотографий для интернет-магазина?

    dimonchik2013
    @dimonchik2013
    non progredi est regredi
    классика для учета фоток
    www.extensis.com/digital-asset-management/portfolio
    Ответ написан
    Комментировать
  • Как организовать процесс съёмки, учёт и хранение фотографий для интернет-магазина?

    В паблике вероятно нет, это не сложно, дата у вас есть в meta фотки, артикул придётся прописывать к каждой фото вручную при выгрузке с фотика на диск. Дальше проходимся по папке с фото специальной программой написанной для вас на заказ (рублей в 500 уложитесь) она забирает дату и артикулы фоток, складывает их в xml/json/txt потом все фото заливаете на сервер в одну папку, скрипт на php разбирает текстовик, кладёт всё в БД. Всё у вас есть возможность поиска по дате съёмки, артикулам и любым другим атрибутам которые вы к фоткам заполните. Можно без веб-сервера в какую ни будь 1Ску наверное класть.
    Ответ написан
    1 комментарий
  • Какой php фреймворк наиболее прост в освоении?

    hbuser
    @hbuser
    Мои пять копеек. Laravel - молодой фреймворк, но современный и очень хорошо проработан. Поддерживает много разных современных плюшек изначально, из коробки (например, PSR-4, composer, как основное средство установки расширений и пр.), на которые некоторые фреймворки, которые существуют больше, чем Laravel только перебрались. Отличается тем, что в нем очень многое достаточно человекопонятно и логично. Создан быть простым. Многое может. Создано много расширений для него (по сути, это любое расширение, которое можно установить с помощью composer, а это 77 тыс. штук расширений, адаптированное для Laravel, что тоже не сложно, но можно и без этого. Не будет сильно удобно, но жить можно.), а если чего-то нет, то packagist предложит все, что душе угодно и установить это дело 2-х минут. Около него очень быстро продолжает расти сообщество единомышленников. Очень много информации по нему на stackoverflow и вообще в интернете. Есть IRC-чаты, в которых много понимающих людей и можно получить помощь в любое время дня и ночи. Есть ребята, которые посвящают себя урокам по нему и делают это очень качественно. Возьмем того же Jeffrey Way. Красавец в плане подачи информации и произношение отличное, американское, не британское. Слушать одно удовольствие. На западе про него знают и разработчики востребованы, у нас его знают плохо. Только относительно продвинутые и открытые новому разработчики. Я настоятельно рекомендую этот фреймворк. Он прост - раз. Он научит работе с различными современными сопутствующими технологиями. Например, из коробки доступен box для vagrant. А это уже немного другой уровень в сравнении с WAMP на Windows.
    Сейчас на базе Laravel уже и микрофреймворк доступен.
    Кстати, в IRC можно задать вопрос и самому автору.
    Еще момент. Автор не городил своих велосипедов. Это качественный продукт. Многое хорошо работающее и хорошо себя зарекомендовавшее там из Symphony, очень многое. Своеобразная квинтэссенция существующих наработок, технологий + свои наработки и своя логичная интерпретация работы с фреймворком.
    Ответ написан
    2 комментария
  • Какой php фреймворк наиболее прост в освоении?

    @ishipilov
    рекомендую codeigniter. Тут писали что он труп, но это не так, недавно вышла 3 версия. Имхо это самый лучший фреймворк, в нем есть все что нужно для фреймворка и ничего лишнего.
    Ответ написан
    Комментировать
  • Какой php фреймворк наиболее прост в освоении?

    это вопрос не более чем выбора религии..
    если в будущем больше планируете взаимодействовать в русскоязычными разработчиками, скорее Yii2, если с англоговорящими - Laravel, или бросьте монетку, или оба попробуйте
    Ответ написан
    2 комментария
  • Какой php фреймворк наиболее прост в освоении?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Silex, но лучше Symfony

    Тут советовали еще codeigniter, вот его не стоит смотреть, это труп.
    Ответ написан
    2 комментария
  • Какой php фреймворк наиболее прост в освоении?

    @Chelman
    Для русскоязычного разработчика, самый лучший вариант - Yii2.
    Большое количество видео на YouTube о том как вести разработку, хорошая книга Марка Сафронова, русская документация, русскоязычный чат на Gitter и русскоязычный форум.

    Так что есть все шансы быстро понять что и как устроено, найти ответы на возникшие вопросы.
    Информация о других фреймворках в такой же полноте имеется только на английском языке.
    Ответ написан
    Комментировать
  • Какой php фреймворк наиболее прост в освоении?

    iiifx
    @iiifx
    PHP, OOP, SOLID, Yii2, Composer, PHPStorm
    Вот список самых популярных фреймворков на Гитхабе GitHub

    А самый простой по моему мнению это CodeIgniter. Но он сильно устарел и годится лишь для изучения, для быстрого старта.
    Ответ написан
    Комментировать
  • Какой php фреймворк наиболее прост в освоении?

    toxicmt
    @toxicmt
    CTO at hexlet.io
    Самыми быстрыми и максимально простыми считаются микрофреймворки, которые берут начало от рубишной синатры (www.sinatrarb.com/). Они практически не отличаются друг от друга, знаете один знаете все другие на всех других языках). В php популярны два www.slimframework.com и lumen.laravel.com/.

    Как минимум с них стоит начинать изучение если вы до этого с фреймворками не работали.
    Ответ написан
    1 комментарий
  • Какими инструментами пользуются дизайнеры сайтов?

    tragische
    @tragische
    let me google this for you
    Без сарказма, бумага, карндаш, ножницы и клей даже иногда. Экономят кучу времени. Лично для меня интерфейс мозг → рука → карандаш самый быстрый и самый гибкий.

    А дальше уже зависит от команды. Если у всех Скетч, то Скетч. Если фронтенд под виндой сидит, то ФШ. Мне долго был мил иллюстратор, из-за векторности, но с появлением Скетча это прошло, хотя иконки в нём мне удобней рисовать до сих пор.
    Уже написали несколько раз про инвижн, он незаменим, особенно для арт-директорской работы и согласований. Ну и он как тудушка для графики отлично работает. Еще есть всякие https://webflow.com/, бывает очень удобно. Не всегда, не для всего, но когда что-то простое, вроде лендингов, то сильно укорачивает время разработки.

    По-факту рисовать всё равно в чём. Важно из чего ваш конкретный фронтэндер умеет/может извлекать информацию.
    Ответ написан
    Комментировать
  • Какими инструментами пользуются дизайнеры сайтов?

    dom1n1k
    @dom1n1k
    Макеты в 99% случаев делаются в PS, Sketch и AI (по субъективному убыванию популярности).
    Пару-тройку лет назад наблюдался взлёт Fireworks, но потом эта мода быстро сошла. Я пробовал - безусловно есть некоторые плюсы, но по совокупности не удовлетворил. Сейчас им пользуются только единицы фанатов.
    Ответ написан
    Комментировать
  • Как вы делаете дизайн сайта?

    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 комментария
  • Как вы делаете дизайн сайта?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    ТЗ - устаревшая и не нужная хрень.

    1. В общении с заказчиком делаете заметки в произвольной форме.
    2. Пользуясь инструментом для создания Wirefames (раз, два), создаёте концепт всех страниц сайта. Чем больше деталей, тем лучше.
    3. Согласовываете с с заказчиком этот концепт (при желании его можно подписать как приложение к договору)
    4. Создаёте пару тройку цветовых решений, согласовываете. Можно даже накидать такой же фрейм в нужных цветах.
    5. Собственно рисуете сам дизайн строго по фреймам.
    Ответ написан
  • Как вы делаете дизайн сайта?

    Sanes
    @Sanes
    Начните с интервью с заказчиком. Дальше по ситуации.
    Ответ написан
    1 комментарий
  • Как в modx revo передать и получить get значение?

    Afres
    @Afres
    Product Owner
    Если стоит дополнение getPage, то есть простая конструкция [[!#GET.sorting]]
    ! - чтобы не кэшировался
    # - чтобы фильтровался от зловредителей
    Ответ написан
    Комментировать
  • Устаревает ли Ruby/RoR?

    Jeiwan
    @Jeiwan
    Рельсы уже перестали быть хипстерским трендом, и это хорошо. Это значит, что технология прошла определенный (подростковый) этап и перешла во взрослую жизнь. Рельсы не умерли, а продолжают активно развиваться и использоваться в разных проектах. Одновременно с этим возникли новые трудности и вопросы: оказалось, что Рельсы не очень-то подходят для больших проектов, слишком они узки для них. Поэтому сейчас довольно много критики в сторону Рельс, много нытья по поводу ActiveRecord, много разговоров о тру-ООП и прочих теоретизирований. В общем и целом, это всё дает возможности для развития Рельс и Руби. Но также многие уходят на Go/Elixir/NodeJs и ещё какую-нибудь хипстоту.
    При этом, сами веб-технологии не особо-то меняются: всё до сих пор работает на HTTP, везде до сих пор используются всё те же реляционные БД, в подавляющем большинстве проектов используется тонкий фронт-энд. То есть можно сказать, что пока жив веб в текущем виде, будут жить и Руби/Рельсы (как и PHP/Python/любой другой язык для веба).

    Руби и РоР - это моё.

    Тогда забейте на популярность и просто работайте. Рельсы — это такой же инструмент, как и любой другой фреймворк на любом другом языке: они позволяют делать всё то же самое. В конце концов, важен результат, важен готовый продукт. Качество продукта в большинстве случаев не зависит от инструмента. Говно можно сделать на чем угодно, говно могут сделать и хорошие инженеры, говно может получиться и по независящим от разработчика причинам.

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

    Слабое место Рельс (а точнее Руби) — отсутствие многопоточности. Поэтому если критически важно количество запросов в секунду, то Рельсы обычно не выбирают и на них не делают таких проектов. Или же используют JRuby, но это как-то совсем редко.

    Сложно ли в России с кадрами по Руби/РоР?

    Сложно, но не невозможно. Массовости нету, но если умеешь работать, то не потеряешься.
    Я лично считаю, что нужно стремиться на Запад, т. к. непонятно, что будет с IT и интернетом в России.
    Ответ написан
    Комментировать
  • Устаревает ли Ruby/RoR?

    @kunashir
    Ruby/Rails программист
    Если все будут думать о том, что вот это устаревает, это не модно - то все будет устаревать и будет не модным... Как Вам написали выше - все этот делают обычные программисты, это же открытые проекты, вместо того чтобы думать о устаревании или модности лучше вносить свой вклад в то, что тебе нравится.
    Ruby для меня очень удобный и выразительный язык, на нем очень приятно вести разработку. Да и не одними "рельсами" живет руби-сообщество.
    Короче: если Вам нравится занимайтесь этим и делайте так чтобы эта экосистема стала лучше. Есть же люди вон, которые на перле пишут свое фремворки аля Рельсы (моджолишес) и не думаю на сколько это быстро устареет и т.п.
    Ответ написан
    Комментировать
  • Устаревает ли Ruby/RoR?

    opium
    @opium
    Просто люблю качественно работать
    ну в разрезе того что у нас средняя продолжительность жизни не большая и пол жизни мы уже прожили, нам срать, какая нам разница устареет ли язык когда на нем будут девелопить наши внуки?
    ну реально смысл думать о том что будет после нашей смерти.
    так рассуждать питьевая вода устареет быстрее
    Ответ написан
    Комментировать