• Как учиться новому после рабочего дня?

    petermzg
    @petermzg
    Самый лучший программист
    Так учитесь новому, до начала рабочего дня. Вставайте раньше, учите нужное, затем на работу, а после работы отдых.
    Ответ написан
    7 комментариев
  • Где найти честного программиста на почасовую оплату?

    borisdenis
    @borisdenis
    Ленив и вреден...
    Программиста с почасовой оплатой без траты ни минуты учтенного времени на "чай" Вы никогда не найдете, на условия с тотальным контролем никто за обычную плату не согласится, только с хорошей наценкой и то маловероятно.
    Вам наверное лучше четко обговаривать сроки выполнения и отдельно оговорить что в случае превышения сроков уменьшать итоговую сумму оплаты допустим на 5% за каждый день просрочки по вине исполнителя. Ну и само собой в ТЗ должны быть оговорены все требования к продукту и используемые технологии. В случае дополнительного "хочу вот эту плюшку" с Вашей стороны срок обговаривается заново.
    Ответ написан
    4 комментария
  • Есть ли бесплатные площадки крутых макетов?

    werty1001
    @werty1001
    undefined
    Ответ написан
    Комментировать
  • Стоить ли изучать Elm?

    easimonenko
    @easimonenko
    Любитель
    Мне понравилось писать SPA на Elm. Синтаксис лаконичный. Проще Haskell, при этом местами даже лучше него. Архитектура понятная и прозрачная, никакой магии. Для быстрого обновления DOM используется Virtual DOM. В скомпилированный код добавляется небольшой runtime. Только client side.

    Правда столкнулся с runtime-багом по undefined, чего в Elm не должно возникать. Скорее всего это говорит о том, что Elm ещё действительно "не готов к продакшн".

    Написал недавно статейку об инструментарии разработчика на Elm.

    Русскоязычное сообщество
    Ответ написан
    1 комментарий
  • Почему фрилансеры готовы общаться только в чате?

    sadisme
    @sadisme
    font-size:30rem
    Всё просто. В 99% ситуаций общения голосом, желают типичные "гуманитарии", которые от темы разработки бесконечно далеко. Ты им говоришь "напишите ТЗ", а они в ответ "давайте я лучше вам всё по телефону расскажу". Они думают если не разбираются в вопросе и не могут ТЗ написать, то уж голосом точно всё объяснят как надо. И не дай бог вам согласиться (а просят как правило настойчиво, ибо самим лень разбираться в вопросе и что-то писать), вынесут вам мозг по полной.
    Ответ написан
    6 комментариев
  • Как в EMMET + JADE реализовать такой подход?

    @bagahunda
    В emmet есть встроенные фильтры, которые указываются в конце строки после |.
    Это странно, но многие про них не знают.
    В вашем случае нужно использовать сразу два фильтра: bem и jade.
    article.post>.__header+.__content+.__footer|bem|jade

    Это развернется в привычный JADE
    article.post
                  .post__header
                  .post__content
                  .post__footer

    Настроить вывод фильтров можно здесь:
    Preferences -> Package settings -> Emmet -> Settings - User

    Вот пример настройки:
    {
      "syntaxProfiles": {
        "html" : {
          "filters" : "html, bem"
        }
      },
      "preferences": {
        "bem.elementSeparator":"__",
        "bem.modifierSeparator":"--",
        "bem.shortElementPrefix":"-"
      }
    }

    Еще есть отличная штука Bemto
    Ответ написан
    1 комментарий
  • На чем лучше и быстрее написать парсер (PHP)?

    muhammad_97
    @muhammad_97
    PHP-разработчик
    DiDom: https://github.com/Imangazaliev/DiDOM

    + высокая скорость работы (сравнение с другими парсерами)
    + хорошая дока
    + большое количество поддерживаемых селекторов
    + самое главное - тесты

    Простой пример:

    $document = new Document('http://www.example.com/', true);
    
    echo $document->first('title::text');


    Чуть посложнее - парсим все ссылки:

    $links = $document->find('a[href]::attr(href)');
    
    var_dump($links);


    Еще сложнее - получить адреса всех ссылок-картинок:

    $links = $document->find('a[href]:has(img)::attr(href)');
    
    var_dump($links);


    Другие варианты:
    - Symfony DomCrawler
    - Zend Dom Query
    Ответ написан
    3 комментария
  • Как увеличить скорость разработки и внимательность?

    Xenobyte
    @Xenobyte
    Насчет внимательности: https://toster.ru/answer?answer_id=690893#comments...
    По поводу скорости разработки: попробуй поработать по методологии скрама (хоть она и для команды), в начале каждого спринта берешь задачи из бэклога, планируешь их на неделю, и смотришь что успеваешь сделать, запланированное тобой должно утвердиться заказчиком (начальником), пусть делит задачи на срочные и не очень, в конце спринта сдаешь ему. В течении спринта, каждый день отчет о том, что сделал вчера, что будешь делать сегодня.
    Ответ написан
    2 комментария
  • В каких случаях вы использовали Redis?

    @chronic86
    Ruby on Rails junior
    1. Хранилище сессий и профилей пользователей;
    2. Сервер очередей, плюс держим в уме механизм publish/subscribe;
    3. Полноценная замена Memcached, притом в случае с Redis мы получим репликацию, более длинные ключи и значения, возможность восстановления кэша с диска и тп;
    4. Место для хранения количества пользователей онлайн, кодов капч, различных флагов, саджестов поисковых запросов;
    5. СУБД для небольших приложений — сокращалок ссылок, имиджбордов, возможно даже блогов;
    6. Роль «словаря» в шардинге, то есть сервер, который знает, какие шарды на каких серверах искать;
    7. Хранилище промежуточных результатов вычислений при обработке больших объемов данных;


    eax.me/redis
    Ответ написан
    Комментировать
  • Как уйти с распутья технологий?

    easimonenko
    @easimonenko
    Любитель
    У Вас высокая степень любознательности. Это очень хорошо! А вот что Вам делать дальше, я так думаю, никто Вам не поможет понять. Есть много статей на эту тему. Чаще всего встречается совет: делайте то, что хотите Вы, а не то, что хотят другие. А для этого нужно мужество и решимость. Как в одной песне: "новая жизнь не даётся даром". И ещё, в противоположность тому, что пишут здесь большинство, я советую сразу искать работу в том направлении, которое Вам больше всего интересно, а не устраиваться на любую, лишь бы платили зарплату, а там посмотрим...

    И да, ещё вот что: в некоторых направлениях разработки требуется более фундаментальная подготовка, чем "выучил язык N за 24 часа". Советую выделить время на ежедневное прохождение соответствующих курсов на таких ресурсах как Coursera, Stepic. Здесь потребуется также настойчивость и терпение, но зато Ваша любознательность станет более конкретной, более контролируемой. Сначала Вы будете хвататься за всё что "блестит" и бросать не доводя до конца, не отчаивайтесь, какие-то вещи всё-равно должны будут Вас реально затянуть так, что Вы почувствуете, что это то, чем Вы бы хотели заниматься. Не зря же говорят: человек находит время на то, что действительно хочет.
    Ответ написан
    6 комментариев
  • Как уйти с распутья технологий?

    @0x131315
    Стратегию уже подсказали: найти любую работу, чтобы кушать, и тем самым выиграть время на изучение чего-то, что поможет зарабатывать больше, и тем самым выиграть еще больше времени, и в конце концов изучить то, благодаря чему будешь работать не на зарплату, а на удовлетворение.

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

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

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

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

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

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

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

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

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

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

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

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

    С третьим - придешь, когда поймешь, что тебе это нужно. Из-под палки не учатся.

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

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

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

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

    Сложность задачи не особо влияет на мотивацию, а вот факт решения/нерешения - влияет сильно. Не решил - значит не осилил, не осилил - значит не достоин, не достоин - значит иди ко дну и не рыпайся. Это как импотенция: импотент - значит не мужик, не мужик - значит никто, ничего не достоин и об тебя можно ноги вытирать. Подсознание портит всю малину, так что не следует давать ему шанса - лучше решить задачу попроще, чем не решить по сложнее.
    Ответ написан
    7 комментариев
  • Верен ли такой подход к изучению программирования?

    Denormalization
    @Denormalization
    В современном мире 80% задач решается копипастом чужого кода и небольшой правкой. (Британские учены доказали).
    Для типовых задач уже давно существуют готовые решения. Не нужно изобретать велосипеды, а тем более комплексовать из-за этого.

    Вам же стоит не просто копировать чужой код и разбираться в нем, но и попробовать его воспроизвести.
    Т.е как-то так:
    - Копипастим
    - Разбираемся почему и как оно работает
    - Удаляем все, создаем новый проект и пишем все с нуля без подсказок (ручками).

    Такой подход будет более эффективен.

    Но все люди разные, и каждый обучается так, как ему удобно. Если вы считаете что вы хорошо усваиваете материал подобным образом, то ничего страшного в этом нету. Просто попробуйте воспроизвести результат с нуля, и если у вас получится - вы действительно усвоили как это делать.
    Ответ написан
    3 комментария
  • Сколько исследователи тратят времени на поиск уязвимости и написание эксплойта подобного рода(в описании)?

    Не знаю, где вы читали эту новость, но по этим двум источникам выходит, что большую часть написанного в вопросе вы сами придумали, и все намного проще:
    gtlaunch.ru/hakeryi-iz-anonsec-ugnali-u-nasa-bespi...
    https://xakep.ru/2016/02/02/anonsec-nasa-leak/

    Итак, смотрим:
    Так как к трояну Gozi группа отношения не имеет, хакеры пишут, что они попросту купили доступ к зараженному серверу у автора Gozi, и сервер стал отправной точкой входа.

    Ну т.е. они даже эксплоит не покупали. Даже если б купили - ну приватный эксплоит, обычное дело.
    Безопасность НАСА действительно оставляла желать лучшего: запустив обычный брутфорс, хакеры нашли первое сочетание логина и пароля root:root через 0,32 секунды.

    Закрепились на одной машине, стали сканить с неё все доступные во внутренней сети - простое и логичное действие. root:root это конечно полный фэйл, и можно сказать удача для AnonSec, но в принципе не так уж удивительно и невероятно.
    Хакеры смогли получить полный доступ к сетевым хранилищам данных (NAS) на которых хранились копии всех планов полетов беспилотников

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

    Получили доступ к NAS (снова root:root, или зашли с доверенной машины, или насобирали паролей разных юзеров и какой-то подошел к NAS), смогли заливать свои файлы. Вот и залили.

    Я не говорю, что со всем этим справился бы школьник, но где вы тут видите что-либо про взлом прошивки? И да, про "закрытые данные":
    взломать внутреннюю сеть НАСА и провести в ней несколько месяцев, а в качестве доказательства они опубликовали архив объёмом 276 ГБ

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

    И под каждый беспилотник никто новую ОС писать не будет. И для серверов НАСА тоже никто новую ОС писать не будет. В беспилотнике будет какой нибудь embedded-дистрибутив, на серверах ну допустим какой-нибудь олдскульный UNIX (AIX/HP-UX/etc), а на новых будет Линух.

    даже софт для управления этим беспилотником

    Ну софт не найдешь, а вот gpx формат известен весьма широко.

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

    Fahrenhe17
    @Fahrenhe17
    Ruby on Rails developer
    В Atom есть плагин, чтобы запускать код - script.
    Для браузера есть cloud9. - по мне так очень хороший вариант, лучший для обучения.

    P. S. VIM наше все.
    Ответ написан
    4 комментария
  • Как правильно замерять время?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Если Вы занимаетесь решением поставленной задачи в рамках проекта Заказчика, то любые действия - должны быть оплачены.
    Даже, если Вы собираете консилиум по скайпу.
    Ответ написан
    9 комментариев
  • Стоить ли изучать Elm?

    @potan
    Функциональный программист
    Однозначно.
    Реактивное программирование очень перспективно, и не только во фронтенде. А здесь оно в наиболее чистом виде.
    Язык и его экосистема уже достаточно развиты и хорошо подходят для быстрой разработки интерфейсов - код компактный и читабельный, есть мощные средства отладки и тестирования (за счет функциональной чистоты).
    Познакомиться с альтернативными парадигмами и синтасисами полезно, хотя бы что бы по новому взглянуть на традиционные.
    Ответ написан
    Комментировать
  • В чем моя причина провала тестового задания Яндекса?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ну давайте я покритикую:

    возьмем файлик

    1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

    class Travelsort {
        constructor() {}
        sortTickets(tickets) {}
    }


    2) вы не умеете пользоваться исключениями.
    if (!Array.isArray(cards)) {
        throw new ValueError('Wrong input');
    }


    3) использование let там где должен использоваться const

    4) в принципе использование переменных там где их быть не должно

    5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

    6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

    7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

    8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

    Далее... берем следующий файлик

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

    2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

    Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

    3) очень много дублирования.

    4) очень плохо с protected variations.

    Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.
    Ответ написан
    17 комментариев
  • Стоит ли использовать табличную верстку, на примере Toster.ru?

    Lynn
    @Lynn
    nginx, js, css
    А теперь уменьшайте ширину окна браузера и посмотрите как меняется страница. И подумайте сколько времени и усилий понадобится что бы сверстать так же на таблицах. И получится ли вообще.
    Ответ написан
    Комментировать
  • Стоит ли использовать табличную верстку, на примере Toster.ru?

    zooks
    @zooks
    Frontend
    Табличная верстка - это начало нулевых.
    Сейчас нужна даже не div верстка через float, а семантическая с использованием Flex.
    Ответ написан
    Комментировать
  • Какой онлайн сервис использовать для построения схемы бд?

    albeal
    @albeal
    бедный студент
    https://www.draw.io/
    Использовалась для построения ER диаграммы
    Ответ написан
    1 комментарий