Задать вопрос
  • Разместить сайт Wordpress на Github Pages?

    sim3x
    @sim3x
    Гитхаб пейджес предназначен для статических сайтов без бекенда
    Ответ написан
    Комментировать
  • Какие математические знания нужны чтобы изучить C?

    GavriKos
    @GavriKos
    Учить ЯЗЫК можно вообще без математики. Тут скорее логика нужна.
    А вот РЕШАТЬ ЗАДАЧИ с ИСПОЛЬЗОВАНИЕМ выученного языка - тут зависит от задачи. От минимального школьного до вышмата.
    Ответ написан
    Комментировать
  • Как открыть сайт через docker?

    profesor08
    @profesor08
    Во первых, там выделено, что нет такого пути к сайту, видимо.
    jmCH8tc.png

    Во вторых, там написано что грохнулся mysql, возможно не стоит использовать InnoDB
    Ответ написан
    3 комментария
  • Как наиболее производительно сделать такой список?

    @StockholmSyndrome
    сначала бы привести к более удобной структуре
    spoiler
    const groupedData = data.reduce((acc, {sport, sub}) => {
      const elem = acc.find((item) => item.sport === sport); 
      if (elem) {
        elem.subs.push(sub);
      } else {
        acc.push({
          sport, 
          subs: sub ? [sub] : []
        });
      }
    
      return acc;
    }, []);

    const $ul = $('<ul>', {
      id: 'list'
    }).appendTo('body'); 
    
    const elems = groupedData.map(({sport, subs}) => {
      return `
        <li>${sport}<ul>
            ${subs.map((sub) => `<li>${sub}</li>`).join('')}
          </ul>
        </li>
      `;
    }).join('');
    
    $ul.append(elems);
    Ответ написан
    5 комментариев
  • Есть ли сервисы для генерации регулярных выражений?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    То, что вы хотите, не решается регулярными выражениями в принципе.
    Для этого нужен интеллект.
    Ответ написан
  • Можно ли это переписать на ООП? И как примерно всё это можно распределить по классам?

    glaphire
    @glaphire Куратор тега PHP
    PHP developer
    Попробуйте натянуть этот функционал на несложный фреймворк вроде laravel - да, он не идеальный, но как по мне лучше начать делать хоть как-то, а потом постепенно разбираться, как писать ООП красиво.
    Items, users, images - могут стать классами моделей, где описаны их свойства и методы для их получения/записи.
    Из function_images можно написать модуль (условно говоря папочку с набором классов-сервисов), где будет описана логика ресайза отдельно, логика обрезки отдельно и т.д.
    Ответ написан
    Комментировать
  • Можно ли это переписать на ООП? И как примерно всё это можно распределить по классам?

    php666
    @php666
    PHP-макака
    классы это просто способ организации кода насколько я понимаю
    нет. вообще не правильно понимаешь.

    Я тебе уже советовал читать Фаулера, ты это сделал? Ты задаешь одни и те же вопросы, на которые в принципе никто не сможет тебе ответить - это тема целой книги. Все советы тут будут лишь медвежьей услугой.

    У тебя два пути:
    1. Брать фреймворк и писать с нуля
    2. Читать книгу и изобретать велосипед, переписывая свою лапшу на оо-стиль. Прокачаешься, но времени потратишь оооочень много, что будет крайне сомнительным действием в плане профита.
    Ответ написан
  • Как поменять стиль по клику на чистом Javascript?

    0xD34F
    @0xD34F Куратор тега JavaScript
    .one path {
      fill: #909090;
    }
    .one.active path {
      fill: #f00;
    }

    const itemSelector = '.one';
    const activeClass = 'active';

    document.addEventListener('click', function(e) {
      const el = e.target.closest(itemSelector);
      if (el) {
        el.classList.toggle(activeClass);
      }
    });
    
    // или
    
    document.querySelectorAll(itemSelector).forEach(function(n) {
      n.addEventListener('click', this);
    }, e => e.currentTarget.classList.toggle(activeClass));
    Ответ написан
    1 комментарий
  • Как (и возможно ли) дотянуться до Junior JavaScript Developer в кратчайшие сроки?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Во первых: совершенству нет предела.
    Во вторых: невозможно объять необъятное и впихнуть невпихуемое.
    В третьих: как ты не крутись, а технологии развиваются быстрее, поэтому отставание неминуемо, как следствие приходится всегда чем-то жертвовать ради чего-то более важного.

    Итого: заказчика не интересуют твои философские страдания. Его интересует как быстро, качественно и за какие деньги ты решишь его проблемы. Решаешь за разумное время, адекватный ценник и с удовлетворительным качеством - не важно как ты себя именуешь, спрос на тебя будет.

    Джуниористость/синьористость конкретного разработчика - штука весьма условно субъективная. На собственном опыте скажу, что одно дело, когда ты первый и единственный парень на деревне - ты почти что бог, потом с той же головой, теми же руками, опытом и знаниями оказываешься в среде подобных себе, разной степени синьористости божков, и, внезапно, ты сырой джун но с очень хорошим потенциалом.

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

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

    Меня на программирование пропёрло весьма рано, лет в 14-15. Я ощущал собственное безграничное могущество, послушная железяка выполняла любое моё повеление, любой мой каприз, при условии, что он правильно сформулирован. Если железка не делала что нужно, или делала что не нужно, то это всегда была моя вина, это значило что я прокосячился. Подобное осознание настигло меня весьма скоропалительно, после чего мозг начал усиленно дисциплинироваться, и количество лютых фейлов пошло на убыль.

    Коммерческая разработка - это, примерно, от 70% времени/сил на дебаг и фиксы, потому что мало где процессы поставлены грамотно. По хорошему до сего дня (а мне под 40) я только одну команду видел, где процессы прям вообще очень хорошо поставлены и мне посчастливилось какое-то время с ними поработать. За эти несколько месяцев я подрос на целую голову. Самостоятельно достичь сходных результатов было бы весьма затруднительно.

    Сам я сменил стек совсем недавно, начал в конце 15 года, и процесс продолжается до сих пор. Сменил я по одной простой причине - во всех моих прежних проектах большая часть логики с бэка уехала на фронт, и прекраснейший jQuery перестал справляться чуть более чем полностью. Он, по прежнему, хорош, но задачи, которые приходится решать, требуют совершенно других подходов. Для себя я выбрал React, но в целом на рынке имеются альтернативы. По моим данным очень большим спросом пользуется Angular 2+.

    Когда говорят о фронтенд разработке, постоянно говорят о технологиях, стеке, но почти никто не упоминает, что не стеком единым... Существенная часть разработки - это, для начала, понять задачу и построить у себя в голове модель. Заказчики бывают разные, от очень толковых, до очень безтолковых. Соотношение первых ко вторым примерно 1% и всё остальное... Т.е. в большинстве случаев тебе скажут минимум, своеобразно, плюс ты это поймёшь по своему. Потом, по ходу пьесы, в самые неподходящие моменты, начнут всплывать подробности, которые: забыли упомянуть; ну это же очевидно, ты же профи; мы сами не знали, это только выяснилось; ну это же мелочи, мы думаем тебе это будет не сложно; а ты не спрашивал; и т.п....

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

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

    Если ты попадешь в команду, где люди будут понимающие, квалифицированные, процессы выстроены, а джуну задачи будут сгружать джунские, то, считай, тебе крупно повезло. Шансов на это примерно 1%. Особенно учитывая, что джуны это обычно студенты лет в районе 20...

    Когда я менял стек, то я тоже был какое-то время 35-летним джуном. С этим ничего не поделать, потому что, внезапно, стек это не просто так, и имеется масса нюансов, которые с наскоку не освоишь. Чтобы все пощупать, попробовать на зубок, понять и осознать требуется время и усилия, иногда много времени и много усилий. Да, весь прежний багаж служит опорой и поддержкой, и там, где настоящий джун будет копаться недели, ты за пару часов по аналогии поймаешь идею и двинешь дальше. Но эти пару часов никто не отменял, а идей которые нужно отловить сотни, если не тысячи...

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

    Даже если тебе попадается практически идеальный проект, внезапно оказывается, что твоя оперативная память это 5-7+-2 объекта, а удерживать в голове одновременно нужно сотни...

    Зачем я все это рассказываю? Затем, что это реальность, которая для джунов не делает исключений.

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

    У верстальщика в этом плане все проще, потому что его работу видно сразу и невооруженным взглядом. Но просто верстальщик и хороший верстальщик - это земля и небо.

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

    Теперь относительно того что делать - если в бэкграунде нет сильных скиллов по алгоритмике и структурам данных (олимпиады по программированию, универский курс информатики), то прям очень сильно рекомендую прокачать. Будучи наставником на нескольких курсах фронтенда я постоянно встречают студентов, которые "вроде бы" знают язык, но затрудняются скомпоновать пару циклов с условиями, вот буквально просто виснут на неопределенное время, причем без результата. Лично я рекомендую кодварс. Своих студентов я прокачиваю именно там. Достаточно прорешать 30-40 задачек, чтобы базовые скиллы ушли на уровень рефлексов и перестали парить мозг. Правда желательно решать это все с наставником.

    Косвенный бонус тут будет в том, что ты привыкнешь решать задачи на JavaScript. Я когда менял стек, поначалу мыслил на PHP, и подобный финт на кодварс позволил мне переформатировать мышление на JS. Вот мой профиль на кодварс как пруф: https://www.codewars.com/users/iCoderXXI

    Далее, когда ты освоишься в JS практически, очень неплохо будет досконально разобраться в том как работают замыкания и прототипное наследование. Это прям основа основ, и это спрашивают на каждом первом собесе.

    Понять надо настолько глубоко, чтобы легко и просто, с юморком, рассказывать это любой первой встречной бабушке, да так, чтобы та всё поняла... Это вот прям залог успеха в JS, потому что все остальное держится на этих двух китах. В ютубе имеется курс Зоракса (Zorax) и JavaScript Weird Parts, оба про то же самое, первый на русском, второй на инглише. Кантор, безусловно, крут, но эти двое объясняют попроще и понятнее (имхо).

    После этого прокачиваемся в использовании встроенных методов JS, таких как map, reduce, includes, replace и пр. (на том же кодварс)

    После этого нужно прокачаться в ES6+, стрелочные функции, let/const, деструктурирование, рест оператор, классы, промисы, генераторы, async/await, декораторы - без этих продвинутых штук в современных фреймворках ловить нечего.

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

    Потом уже заостряемся на API форм, DOM, AJAX (fetch/axios), вебсокетах, Localstorage и пр.

    И вот только теперь можно переключаться на фреймворки. Проще всего освоить Vue (по слухам), наибольшим спросом пользуются React и Angular, для общего развития так же неплохо бы немного послушать про Ember.JS.

    React только на первый взгляд выглядит простым, на самом деле это только view-библиотека, а в любом нормальном SPA есть много чего еще кроме view, поэтому React всегда идет в компании Redux, Router, и еще целой толпы всего, что тоже придется осваивать, не только с точки зрения API, но и с точки зрения философии (а нахрена оно вообще сдалось?)

    Перед походами на собесы очень желательно иметь портфолио из нескольких готовых проектов, вылизанных стилистически.

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

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

    Еще вроде большие компании вроде Яндекса устраивают летнее обучение, с последующим трудоустройством лучших кандидатов, но это не точно.

    Оптимистичный прогноз - 6-12 месяцев плотного фигачинга и ты в тренде.
    Ответ написан
    7 комментариев
  • Существует ли "карта программиста"? Что и за чем учить?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Нет одинаково эффективного пути для всех и каждого.

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

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

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

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

    Далее из модулей, как из кубиков лего пытаешься собрать функциональные блоки. Тут важно понимать, что чем более автономные модули и блоки у тебя получаются, тем лучше, особенно для целей тестирования. Если ты забиваешь болт на тестирование, то тебе нечего делать в разработке.

    На первых порах, тестирование будет занимать до 99% времени и сил. Заодно подтягивается синтаксис используемых языков (вообще не важно каких), вырабатывается внимательность, концентрация, тренируется память и пр.

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

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

    Только так, только жесткий хардкор! Если ты не прошел эту фазу, то ты либо родился гением, либо тебе нечего делать в профессии... Это как детские болезни - ими нужно переболеть в детстве.

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

    А какими инструментами ты решаешь задачу - дело десятое и в каждом проекте, число которым миллионы, будет свой набор блэкджека с барышнями, так-что загодя готовиться особо смысла нет. Нужно хорошо владеть азами, а остальное осваивать на лету.

    Ах да, обложись справочниками по любому инструменту и научись быстро вникать и подхватывать необходимый минимум. Обычно достаточно на 20% владеть инструментом, чтобы решать 80% задач.

    В любом случае я за критерий истины держу платежеспособный спрос.
    Ответ написан
    3 комментария
  • Как избежать параллельных запросов MySql?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    По-моему, это не вопрос, а очередная влажная фантазия.
    Один и тот же юзер не в состоянии создавать "параллельные запросы".
    Тут скорее логика хромает. Зачем-то сделано удаление записи, дальше идёт какое-то анонимное голосование(?!). почему-то можно ставить плюсы несколько раз.

    Удалите этот вопрос и вместо этого спросите, как сделать голосование нормально. В общем случае все делается 1 запросом.
    Ответ написан
    5 комментариев
  • Нужно ли защищать обработчик формы (PHP файл) от прямого доступа?

    Ninazu
    @Ninazu
    1. Создай единую точку входа, и оставь ее в корне сайта, остальные файлы вынеси за пределы (Это не только сделает твое приложении более гибким, понятным, и структурированным, но и в случае отваливания веб сервера, такое когда-то у меня было, после кривого обновлении до php7, исходный код показывался браузером)
    2. Не забудь про SQL иньекции. Никакой конкатенации или вставок PHP. Только плейсхолдеры и байндинг
    3. Если есть возможность загружать файлы, нужно исключить возможность исполнения в этой папке.
    Ответ написан
    3 комментария
  • Как написать такую кнопку на чистом JS, без jquery?

    Neolot
    @Neolot
    Make the web great again
    Здесь есть аналоги jQuery-методов на "чистом" JS, с примерами:
    youmightnotneedjquery.com
    Ответ написан
    Комментировать
  • Где лучше взять VPS?

    Astrohas
    @Astrohas
    Python/Django Developer
    Из всей троицы OVH, DO и Hetzner, могу порекомендавать последнего, из за соотношения цены/ресурсов.
    К примеру 2GB Ram/70GB SSD /1Cpu обходиться в 4.5 Euro, 2GB Ram/20 SSD /1Cpu - 2.79 Euro
    Ответ написан
    5 комментариев
  • Как зайти в веб-приложение под одними данными нескольким пользователям одновременно?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Если у вас нет возможности изменить код веб-портала, то никак.
    Ответ написан
    Комментировать
  • Как "конвертировать" зашифрованный пароль с базы данных в нормальный текст?

    inoise
    @inoise Куратор тега PHP
    Solution Architect, AWS Certified, Serverless
    Никак. Хэш от пароля должен быть односторонним. Берем хэш от присланной строки и сверяем результат с тем что в бд
    Ответ написан
    Комментировать
  • Как "конвертировать" зашифрованный пароль с базы данных в нормальный текст?

    delphinpro
    @delphinpro Куратор тега PHP
    frontend developer
    Пароли в базе обычно не шифруются, а хешируются.
    Хеширование необратимо.
    Ответ написан
    2 комментария
  • Что делать если увольняют с работы(IT компания. Скорее всего по статье за несоответствие занимаемой должности)?

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

    Словом, уходите по собственному и при поиске работы объясняйте такой короткий срок. В целом, это нормально - на то испытательный срок и существует, чтобы не только компания к вам присмотрелась, но и вы к компании. Единичная подобная история нормального кадровика не смутит.
    Ответ написан
    4 комментария