Задать вопрос

archelon

Лайки

  • Зачем комментируют перед написанием кода?

    mayton2019
    @mayton2019
    Bigdata Engineer
    Смыслов много. Во первых исходник не всегда отражает намерения разработчика или есть какая-то информация которая лежит вне этого поля зрения. Например фиксится какое-то сложное поведение кода наподобие undefined behaviour и нужно написать сверху комментарий почему именно сделано так. В противном случае другой разработчик может не понять все эти изменения и откатить их или просто выкинуть кусок кода за непониманием. Такова природа людей. Непонятное - откидываем в сторону. А если будет написано :
    // Warning! Do not touch next line of code, because ...


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

    Смысл также есть в авто-документировании для авто-документации. По ключевым словам типа Doxygen, JavaDoc можно посмотреть примеры и туториалы по документированию. Это очень хороший навык который сделает в беспорядочной разработке видимость ведения документации. Тут надо конечно идти от scrum-agile и потребностей бизнеса но бывают также проекты (ведомственные, и прочие промышленные) где это важно, и где требуют сопроводительную бумажку. Тулзов для этого много. Я перечислил только 2 но их больше.

    Вот что точно не надо комментировать так это : твою подпись, дату-время изменений и заголовок JIRA-ticket на основании которого велась разработка. Вся эта инфа всегда храниться в системах версионного контроля и нет смысла ее дублировать дважды.
    Ответ написан
    3 комментария
    3 комментария

  • Путаница с z-index - что я упускаю?

    @Asokr
    Задайте элементу с тенью
    pointer-events: none
    Ответ написан
    1 комментарий
    1 комментарий

  • Хорошее ли решение разделение таблиц юзер и роли?

    @alexalexes
    Вы выделили в системе два класса сущностей. Одна - Пользователь, вторая - Роль.
    Под каждый класс нужна отдельная таблица.
    Как определить какие взаимоотношения между этими классами?
    Нужно примерить следующие коммутативные гипотезы:
    Первая пара гипотез:
    "Один пользователь должен (может) иметь только одну роль."
    "Одна роль должна (может) быть назначена многим пользователям."
    Вторая пара гипотез:
    "Один пользователь должен (может) иметь несколько ролей."
    "Одна роль должна (может) быть назначена многим пользователям."
    Если в вашей архитектуре системы справедлива первая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "один ко многим". Это значит, что у таблицы Пользователь будет внешний ключ в виде идентификатора роли, тем самым вы каждому пользователю сможете назначить только одну роль. Но сами роли могут повторятся у разных пользователей.
    Если в вашей архитектуре системы справедлива вторая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "многим ко многим". Для этого нужно создать промежуточную таблицу, например Пользователь_и_роль, в которой будут два внешних ключа - идентификатор пользователя и идентификатор роли пользователя (можно, но технически нужно еще создать еще идентификатор первичного ключа, чтобы можно было корректно обращаться к записям этой таблицы, не путая их). В этом случае каждому пользователю можно выделить целый набор ролей, не ограничиваясь одной ролью.
    Ответ написан
    Комментировать
    Комментировать

  • Нужно ли Frontend разработчику мониторить обновления?

    AlekseyNemiro
    @AlekseyNemiro
    full-stack developer
    За обновлениями периодически нужно следить, просто, чтобы знать, что меняется, появляется или удаляется из новых версий. Нужно ли обновлять - это уже вопрос потребностей проекта, клиента, команды.

    Я обычно просматриваю изменения ключевых пакетов/библиотек раз в 1-3 месяца.

    В большом проекте ключевые пакеты/библиотеки может быть сложно обновить, особенно если меняется номер старшей (major) версии (например, Bootstrap v4 => v5). Несущественные изменения (minor), в некоторых случаях могут иметь ощутимые последствия, что-то может сломаться или изменится поведение.

    Я бы не стал просто так обновлять такой пакет, как Bootstrap. Если обновление ключевого пакета происходит, то это неизбежно увеличит нагрузку на QA команду (quality assurance - обеспечение качества, тестирование). В случае с Bootstrap, вероятно придется весь проект перетестировать. Без автоматического тестирования будет особенно тяжко.

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

    Если вы используете менеджер пакетов, например npm, то скорее всего он вам будет показывать предупреждения об обнаруженных уязвимостях в пакетах и варианты их устранения. За этим лучше следить, чтобы потом не было неприятных сюрпризов. Как правило, с менеджером пакетов это делать проще, достаточно будет проверить отдельные предупреждения, а не все пакеты.

    Ну и главное, не делать просто так обновления на текущей активной версии проекта. Чем дольше проект с обновленными пакетами будет находиться на тестировании, тем лучше.
    Ответ написан
    Комментировать
    Комментировать

  • Можно ли во время изучения JS больше ориентироваться на практику чем на книги и пользоваться поиском нужных команд?

    @Niksak
    Только так и можно, учить инструменты в бою)
    Теория выветривается
    Ответ написан
    Комментировать
    Комментировать

  • Front-end разработчик обязан уметь верстать в разных программах?

    @alexalexes
    Какой бы программой вы не пользовались, вам нужно уметь всего лишь снимать метрики с графических примитивов с помощью линейки, пипеткой брать цвет, знать как извлечь коэффициент прозрачности и характеристики градиентов, блюров, снимать характеристики шрифта с текста. Больше ценится навык, как вы все эти параметры наиболее быстро запихнете в CSS или напишите шаблон для предпроцессора CSS. И если какая-та программа на выходе получит сырой CSS - как его дошлифовать до конечного результата?
    Ответ написан
    Комментировать
    Комментировать

  • Разница между JavaScript и HTML5 игрой?

    delphinpro
    @delphinpro Куратор тега JavaScript
    frontend developer
    На html игры не пишут. Их всегда пишут на javascript
    Просто так называют игры, которые для отображения используют холст (canvas)
    Такое название сложилось исторически, с тех времен, когда игры в основном писались на флеше. Вот чтобы их как-то обособить игры на js стали называть играми на html5 в противовес флешу.
    Ответ написан
    Комментировать
    Комментировать

  • Как сделать кнопку назад на js чтобы она возвращала назад не по истории браузера, а по хлебным крошкам?

    @furashcka
    Наверняка у вас есть список url из хлебных крошек, если нет то на крайний случай их можно вытащить из html, их можно представить в виде массива: [`site.com/catalog`, `site.com/catalog/sub-catalog`, `site.com/catalog/sub-catalog/item`], имея данный массив находим текущий index по location.href
    let breadcrumbs = [`site.com/catalog`, `site.com/catalog/sub-catalog`, `site.com/catalog/sub-catalog/item`];
let indexCurrent = breadcrumbs.indexOf(location.href);
let indexPrev = Math.max(0, indexCurrent - 1);
let prevURL = breadcrumbs[indexPrev];

location.href = prevURL;


    Как видите вам понадобится массив с url, по которому вы можете возвращаться назад, за счёт currentIndex - 1, пока не дойдёте до главной страницы, у которой обычно index = 0
    Ответ написан
    Комментировать
    Комментировать

  • Как правильно оптимизировать страницу?

    @strelok011
    Оптимизация html и css по сравнению с оптимизацией png - бесполезная ерунда. Вы можете выиграть допустим 2-5 кб против 2-3 мб одного png, в условиях современного интернета этот выигрыш ничего не даст. Даже запрос на сервер может больше времени занять чем скачивание.
    Необходимо обратиться именно к оптимизации png при этом желательно с минимальными потерями по качеству.
    Советую для начала ознакомиться вот с этой статьёй How To Optimize PNG, а потом поискать инструмент поудобнее, просто погуглив PNG optimizer. Вот сравнение нескольких пакетных оптимизаторов. Я при необходимости оптимизации png использую RIOT, он может оптимизировать png, gif и jpg. Из личного опыта - советую попробовать первым делом оптимизацию палитры. Плюс есть не искажающие оптимизации (например, удаление мета-данных). Если используете прозрачность - она сильно добавляет веса в изображение, с ней тоже можно бороться.

    Всё это хорошо, если у вас есть возможность оптимизировать изображения, статично размещенные на сайте.
    Ответ написан
    Комментировать
    Комментировать

  • Чем заменить тег br?

    @AndreyBLG
    "Какое-то слово не хочет переноситься"
    Не ясна конкретная ситуация, но вдруг будет полезно, можно попробовать настроить переносы, используя неразрывный пробел между словами, которые точно не должны быть на разных строках.
    Например, в предложении "Lorem ipsum dolor sit amet", перенос строки происходит так:

    Lorem ipsum
    dolor sit amet

    А нужно, чтобы было так

    Lorem ipsum dolor
    sit amet

    То между "ipsum" и "dolor" можно поставить неразрывный пробел.
    Ответ написан
    5 комментариев
    5 комментариев

  • Почему верстальщики обычно вырезают круглую картинку квадратом?

    ThunderCat
    @ThunderCat
    {PHP, MySql, HTML, JS, CSS} developer
    1) Круглые картинки без фона - это либо пнг, либо вебп (думаю неприменимость формата гиф очевидна и так). Не все картинки хорошо смотрятся в пнг и не все браузеры полностью поддерживают вебп.

    2) Цсс такая штука, специально придуманная для того, чтобы если завтра мода на круглое сменится модой на квадратное, то "легким движением руки брюки превращаются в элегантные шорты". И для этого не понадобится перепердоливать стотыщь картинок обратно в квадраты.

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

    4) Сделать тумб с "круглым видом" программно сложнее чем с квадратным.

    5) Артефакты при нарезке из квадратного в круглое смотрятся хуже, чем, по сути, векторная маска, наложенная на цельное квадратное изображение.

    Короче, не зря делают.

    PS: На дом - научиться самостоятельно искать аргументы в пользу / против какого-либо замеченного технологического приема.
    Ответ написан
    1 комментарий
    1 комментарий

  • Вложение тегов html?

    Lynn
    @Lynn
    nginx, js, css
    Не все элементы можно вкладывать в какие-то другие элементы.

    В частности в тег <p> можно вкладывать только строчные элементы.

    Формальное описание что можно вкладывать в тег можно посмотреть в спецификации или MDN.

    В частности для <p> там написано «Разрешённое содержимое: фразовый контент».

    В случае неправильного вложения браузер пытается починить DOM-дерево как может (на самом деле по определённым правилам которые тоже есть в спецификации) и чаще всего он просто закрывает теги до тех пор пока не получит не доберётся до родителя в котором данный контент разрешён.

    UPD: Вопрос на самом деле довольно неочевидный для новичков, так что есть полезный сайт https://caninclude.glitch.me/caninclude?child=ul&p...
    Ответ написан
    Комментировать
    Комментировать

  • При каких знаниях первого яп можно начинать изучение второго?

    @alexalexes
    Пока не начнете делать проект, решающий какую-то насущную потребность (вашу - без денежного вознаграждения, или чужую - за денежное вознаграждение), можете всю жизнь просто интересоваться хоть одним языком программирования, хоть несколькими.
    Запомните, пока вы вне таких проектов что-то делаете, вы просто интересуетесь инструментарием, вы ничего не учите.
    Ответ написан
    Комментировать
    Комментировать

  • Законно ли брать png материалы из интернета и использовать их в своих работах а также продавать?

    CityCat4
    @CityCat4
    Жил да был черный кот за углом...
    Законно ли брать png материалы из интернета и использовать их в своих работах а также продавать?

    В общем случае нет. У каждой картинки, текстуры, любой завитушки - есть автор, который ее создал. И этому автору принадлежат неотчуждаемые авторские права (то есть те права, которые у него невозможно отобрать и от которых нельзя отказаться), а также отчуждаемые авторские права (которыми обычно и торгуют).
    Автор может лицензировать использование своей работы по любой схеме лицензии, которая взбредет ему в голову - платной, бесплатной, какой угодно, может использовать стандартное лицензионное соглашение или придумать свое.
    Если он разрешает использовать его работы бесплатно (в том числе в коммерческих целях, то есть для перепродажи) - все нормально, если же нет - можно нарваться на УК 146 (это маловероятно, конечно, если у тебя покупателей три калеки, да и автор - такой же, но если вдруг твой проект взлетает или ты случайно обьел заметного автора - готовься к проблемам)
    Ответ написан
    5 комментариев
    5 комментариев

  • "Одинаковые заголовки и описания страниц". Нужно ли исправлять?

    vpetrov
    @vpetrov
    частный SEO-специалист
    Оцените характер трафа, посмотрите, как реализовано у топовых.
    Я не продвигал сайты такого типа, но предположу:
    а) Большой процент трафа должен подразумеваться из "Картинок" ПС. Стало быть, закрывать такие странички в ноиндекс - себе дороже.
    б) Значение имеют страницы категорий и тегов. Тегируйте каталог по классике, делайте, как в больших интернет-магазинах на оценке поискового спроса. Ну банально: есть спрос на "валпейпер 1920 тёмный киберпанк" - нужна категория.
    в) Шаблонизация рулит. Что мешает при загрузке картинки дать ей внятное название, которое будет подставляться в тайтл и дескрип? Ну там по типу "Обои на рабочий стол + Синее море с пальмой + 1920х1080 + скачать бесплатно".
    К этому добавьте микроразметку по картинкам. Она не для сниппетов нужна, а чтобы ПС понимали, чем вот эта страничка с минимумом контента отличается от той, где всё практически идентичное. В индекс всё равно всё не пойдёт, но будет заметно проще с техничкой - как минимум.
    Ответ написан
    3 комментария
    3 комментария

  • Для чего нужен грид в 24 колонки?

    neuotq
    @neuotq
    Прокрастинация
    Чаще всего используют 12 колонок. Причина в сравнении с красивыми 10 проста - большее количество вариаций делений при относительно небольшом числе колонок, учитывая исходные что ширина бОльшей часть экранов кратно 8. Поэтому может вернее будет назвать эту систему системой 8-пиксельной, тк шаг в 8 пикселей для большинства размеров(при хард сетке всё кратно 8, при софт только расстояния между элементами). Таким образом легко быстро выстраивается модульная сетка с приятным ритмом.
    Поэтому многие системы/фреймворки по умолчанию настроены на 12 колонок.
    24 колонки - можно условно считать вариацией для любителей чуть большей вариативности и тонкостей с шириной/расстоянием между колонками и шага в 4 пикселя и тонкой настройки золотого сечения на странице.
    Отдельно стоят любители 16 колонок(относительно популярный вариант), это, как другие менее популярные, уже частные случаи сетки и дизайна, где все в ручную подбирается, либо изначально допускается меньшая вариативность размещения элементов/колонок/модулей. Поэтому прям зацикливаться не стоит, исходите из своих задач и требований, полёта фантазии дизайнера.
    Ответ написан
    Комментировать
    Комментировать

  • Заказывать CMS с 0 или использовать существующие?

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

    Далее смотрите, что из требуемого функционала уже есть в CMS (хотя бы похожее или что CMS позволяет быстро реализовать), а что носит уникальный характер, заточенный именно под ваши нужны. Чем больше уникального функционала, тем больше плюсов в написании с нуля, ну и наоборот, чем проект более типовой (новости, статьи, каталоги, фотогалереи, формы обратной связи и т д), тем выгоднее брать CMS.
    Ответ написан
    1 комментарий
    1 комментарий

  • Какова нагрузка от использования слайдер Swiper?

    TTATPuOT
    @TTATPuOT
    https://code.patriotovsky.ru/
    Вам кто мешает сделать сначала, а потом уже, при условии, что всё будет глючить, переделать? 20 штук - не так и много, к тому же все они используют одну кодовую базу.
    На готовом решении вы эти слайдеры соберёте условно за 1 час все. Чтобы написать своё у вас уйдёт часа 2 только на то, чтобы продумать структуру общую для всех слайдеров. Сделайте сначала простой вариант. Если не сработает - будете думать, как оптимизировать.

    На Swiper свет клином не сошёлся, есть слайдеры и попроще, и полегче. Вариантов масса:
    https://glidejs.com/
    https://www.embla-carousel.com/
    https://nickpiscitelli.github.io/Glider.js/
    https://swiffyslider.com/
    https://splidejs.com/
    https://github.com/RensTillmann/CarouselJS
    https://github.com/rchisholm/vanilla-slider
    Ответ написан
    1 комментарий
    1 комментарий

  • Что делать в такой ситуации, когда заказчик не оплачивает сделанный заказ?

    dimonchik2013
    @dimonchik2013
    non progredi est regredi
    херней страдаешь

    если не первый раз и предыдущие ОПЛАЧЕНЫ - радоваться надо

    если чел говно - больше не обратится, обратится - у тебя есть повод отказать, и заберешь и предоплату возьмешь
    если не говно - , и заберешь и предоплату возьмешь

    так что оставляй как есть и просто ЖДИ
    фишка в том что нанять делавшего на доработки дешевле нового
    Ответ написан
    Комментировать
    Комментировать

  • Как создать язык программирования?

    VoidVolker
    @VoidVolker
    Dark side eye. А у нас печеньки! А у вас?
    Как создать свой язык программирования?

    Точно так же, как и любую другую программу: сначала спроектировать, а потом реализовать.

    Без другого языка программирования! Полностью с нуля.

    В самом низу находится машинный код. Выглядит примерно вот так:
    08 04 83 fa 08 04 83 fb 08 04 83 fd 08 04 84 00
    У каждого процессора есть свой набор инструкций, которые кодируются машинным кодом. Открываем справочник и пишем нужный код для нужной ОС/железа. Ничего сложного, правда же? =)

    Ведь как-то создали первый ЯП.

    Достаточно почитать историю появления первых ЭВМ. Они представляли из себя набор переключателей отдельных битов, которые позже эволюционировали в перфокарты, которые в свою очередь представляли из себя прообраз современных исполняемых файлов. С увеличением количества доступных команд, усложнением техники и появлением накопителей программы так же становились все сложнее и сложнее: поэтому решили упростить запись и придумали первый ассемблер. Дальнейшее развитие привело к появлению первого ЯП высокого уровня и далее более высокие уровни абстракции, используя которые сегодня пишутся все программы.

    Так что в вашем случае вам надо пройти весь этот путь самостоятельно. Примерно так:
    1. На машинном коде реализовать минимальный ассемблер
    2. Используя свой минимальный ассемблер реализовать простейший компилятор этого ассемблера
    3. Расширить компилятор ассемблера до стандартного набора инструкций
    4. На ассемблере реализовать транслятор и компилятор ЯП высокого уровня
    5. Реализовать необходимый набор инструкций для написания компилятора этого же ЯП
    6. Написать этот самый компилятор своего ЯП на нём же и далее уже скомпилировать первую самостоятельную версию своего ЯП без использования других ЯП
    Ответ написан
    3 комментария
    3 комментария