• Какую хорошую литературу посоветуете с задачами на Python?

    aRegius
    @aRegius
    Python Enthusiast
    Ответ написан
    Комментировать
  • Какую хорошую литературу посоветуете с задачами на Python?

    @sash999
    просто админ из деревни
    Попробуйте https://checkio.org/ - там как раз лучшие решения и вообще решения других можно посмотреть только после того, как сам решишь. Но там по-английски всё.
    Ответ написан
    1 комментарий
  • Где брать задачи на python?

    Ответ написан
    Комментировать
  • Где брать задачи на python?

    @marxxt
    понравился ответ - поставь ✔
    Ответ написан
    Комментировать
  • Где брать задачи на python?

    dezzignet
    @dezzignet
    Ответ написан
    Комментировать
  • Необходимый стек навыков\умений на стажировку?

    @Bruceee
    1. Скорее всего ответ на ваш вопрос гуглится, люди часто пишут вопросы с собеседований и т.д. Насколько я знаю, там три интервью, одно из них на программирование (общее умение писать код, если завалите, сразу отказ), второе на алгоритмы (если не пройдете здесь, то все равно могут взять), а вот про третью часть точно не вспомню. Советую также посмотреть на glassdoor.com, возможно там есть отзывы о собеседованиях в Яндексе.

    2. Помимо самих навыков обязательно необходимо прокачать умение проходить собеседования. Для этого есть бесплатный сервис для собеседований pramp.com
    Ответ написан
    Комментировать
  • Необходимый стек навыков\умений на стажировку?

    saboteur_kiev
    @saboteur_kiev Куратор тега Python
    software engineer
    Почитайте вакансии, почитайте готовые резюме, посмотрите что спрашивают.
    В идеале попробуйте до интервью добраться.
    Не ставьте цель только стажировку, может самоучкой до нормального джуна дойдете.

    Если есть знакомые, которые уже работают, попросите их вас пособеседовать, или чтобы их коллеги провели поддельное интервью.
    Ответ написан
    Комментировать
  • Как развиваться Junior-у PHP?

    Sanasol
    @Sanasol Куратор тега PHP
    нельзя просто так взять и загуглить ошибку
    3. Развиваться в самом бекенде - php

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

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

    Если хочется изучать, изучайте в свободное время что угодно, но цель стать фуллстаком это так себе вариант.

    Конечно же написанное всё имхо)
    Ответ написан
    3 комментария
  • Дизайн с нуля: какие основные этапы работы?

    lukoie
    @lukoie
    0 заводим асану, и гуглодокс-папку в "проектах" под проект
    1 берем из шаблонов заготовку для брифа и клиент заполняет
    2 создаем на его основе ТЗ и утрясаем с заказчиком(ЛПР)
    3 создаются эскизы страниц
    4 на их основе - мокапы
    5 на их основе - вайрфрейм
    6 прототип
    7 создается окончательный продакшн дизайн
    8 проводится ДТП, допиливается всё по внутренним стандартам(именование слоев, группы, название файлов, лишний мусор внутри и т.п.)
    9 чистится файловый мусор и бекапится
    10 передаем заказчику окончательный вариант

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

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

    Это как в шахматах средние игроки думают во время дебюта, а опытные просто играют по памяти свой любимый дебют и почти не думают над ходами во время дебюта. А такие мастера как Магнус Карлсен могут выиграть за 30 секунд у большинства средних игроков. Выглядит это пугающе(https://youtu.be/NTEj4moaay0 )

    И примерно такая же разница между слабыми и сильными программистами. Это прежде всего физиологические различия и различия в уровне подготовки. Книги про продуктивность тут не увеличат производительность каким то радикальным образом. Скорее наоборот если человек со слабыми природными данными начнет много программировать то у него быстро наступит выгорание, потому что его ЦНС физиологически на это не способна и производительность в результате может упасть.
    Ответ написан
  • Какие книги полезны для повышения эффективности одного программиста?

    ApeCoder
    @ApeCoder
    • "Рефакторинг: улучшение существующего кода"
    • "Программист-прагматик"
    • "Эффективная работа с унаследованным кодом"
    • "Чистый код"
    • "Code complete"
    Agile, scrum, kanban наверно тоже больше для команд .


    Общий подход может применяться и индивидуально. Еще можно прочитать про Getting Things Done
    Ответ написан
    Комментировать
  • Верстка с нуля: какие основные этапы работы?

    Hyubert
    @Hyubert
    JS
    - win+r
    - cmd
    - cd ../
    - git clone
    - npm i
    - sblm project_name
    - npm start
    Ответ написан
    3 комментария
  • Верстка с нуля: какие основные этапы работы?

    @skeevy
    Frontend WebDev
    0) Включаю музыку, проверяю обновления пакетов и npm =)
    1) Клонирую из собственного форка немного переделанный OptimizedHTML
    2) Визуальный анализ макета, загрузка в AdobeAssets/Avocode
    3) Составление типографики, подключение шрифтов
    4) Экспорт графики "как есть", дергаю дизайнера перед сдачей, если необходимо. В целом, оптимизирую графику сам, но ближе к концу
    5) Набрасываю первоначальный html, когда готов - работаю над стилями.
    6) После подготовки десктопа, работаю над адаптивом. Как правило, много времени не занимает, если сам не сделаю говнокод, благо, sass спасает =)
    7) Оптимизирую графику, если необходимо. Прогоняю GooglePageSpeed на своем тестхосте и на github pages
    8) По результатам прогона оптимизирую все остальное (крайне редко)

    Иногда приходится выполнять и другие действия, но в целом моя работа выглядит примерно так

    P.S. Инструменты:
    Редакторы: Brackets, SublimeText3. Очень редко Atom (смотрю в сторону VS Code)
    Консоль: cmder
    Макеты: PSD, sketch через invision.com
    Сборщик: Gulp
    Методология: БЭМ
    Хостинг: GithubPages, собственный хост на hostland
    Ответ написан
    5 комментариев
  • Верстка с нуля: какие основные этапы работы?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Начинается с https://www.mosne.it/playground/mosne-flexbox/
    и этим всё и заканчивается. Он - полностью покрывает все потребности.
    UPD: Когда админка или SPA - иногда подрубаю свой велосипед: xmoonlight.github.io (включая includeHTML)
    UPD2: А вот это для тех, кто любит кодить на jQuery: смотреть ролик.
    Ответ написан
    1 комментарий
  • Верстка с нуля: какие основные этапы работы?

    Krasnodar_etc
    @Krasnodar_etc
    fundraiseup
    1) Определение инструментов, их настройка
    2) Выделение общих/переиспользуемых компонентов
    3) Самое сложное - придумывание названий
    4) Вёрстка
    Ответ написан
    1 комментарий
  • Верстка с нуля: какие основные этапы работы?

    mrerberg
    @mrerberg
    Yep
    Mikhail @NooNoo
    Рубрика "Давай глянем,что там у нас есть". Я использую такие штуки в работе:
    Препроцессор: LESS
    Работа с макетами: PH или Sketch.
    Сборщик: Gulp
    Методология: БЭМ (но начал заглядываться на SMACSS)
    Консоль: консоль :D
    Место хранения репозитория: GitHub.

    1) Создаю репозиторий на гите.
    2) Создаю локально структуру проекта. (папки для картинок и тд).
    3) Открывают макет
    4) Создаю первые наброски в html (создаем классы по выбранной методологии), в голове держим,что mobile first. Подключаю основные фалы препроцессора (шрифты, глобальные стили, миксины, класс visually-hidden, переменные)
    5) Выстраиваю сетку. (flexbox или гриды)
    6) Начинаю стилизовать мобилку -> планшетную -> десктопную версию.
    7) Отшлифовка кода и поиск более рациональных решений, где это допустимо.
    8) Донастройка сборщика, который все в итоге соберет продакшен версию.

    Вкратце как-то так)
    Ответ написан
    2 комментария
  • Верстка с нуля: какие основные этапы работы?

    pavelkarinin
    @pavelkarinin Автор вопроса
    Full Stack Web Developer
    На этот вопрос есть подписчики, не ожидал, что столько, но это говорит о том, что вопрос интересен и это хорошо. Поэтому хоть и я его автор, но отвечу тоже. Я, как человек, который пережил эпохи Mosaic, Netscape и IE (старички меня поймут), отвечу ещё и по той причине, что часто, нет … очень часто сталкиваюсь с тем, что действительно "талантливые" начинающие Front-End тратят попусту свое время, из-за незнания такого, казалось бы, вопроса ни о чем (как выразился Froggyweb) об организации своего workflow и начинают не с того, с чего стоило бы начинать в результате это приводит к тому, что некоторая работа просто дублируется, переделывается и т.д. лишь потому, что изначально об этом не подумал.

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

    Я работаю на трёх мониторах: центральный - вёрстка, левый - результат, правый - дизайнерский макет + чего ещё что надо по ходу пьесы, типа киношки, статейки и т.д.;

    Среда:
    в Visual Studio - для сложных и крупных проектов, плотно подсевших на Back-End;
    в Visual Studio Code - для проектов попроще;
    хе-хе в Блокноте - для совсем простых))

    Музыка – это святое, тем более я её тоже иногда пишу, но слушаю всегда чужую на SoundCloud))

    Создаю папку решения

    Создаю в ней подпапку всегда с одним и тем же имеем: _native_design, в которую (в зависимости от формата портирую дизайн)

    Выбираю явственно общие компоненты страниц (шапка, контент, меню, боковые меню, подвал и д.р.) и для каждого создаю простой пустой файл scss с названием, соответствующим компоненту.

    На этих компонентах выбираю неизменяемые и изменяемые элементы и определяю для них селекторы в соответствующих файлах scss (тут всегда туго с названиями, поскольку от природы я не очень одарён)

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

    Исходя из сетки, и из минимально необходимой версии браузеров (речь конечно же об IE), создаю файл _base.scss который наполняю сбросом стиля, и объявлениями для grid (ну все это не вручную, а сниппетами, импортами, инклудами, которые у меня подготовлены почти на все случаи жизни).

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

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

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

    Потом начинается работа с адаптивностью. Я всегда сворачиваю контент, т.е. начинаю с широкого формата, потом desktop, tablet, mobile. Тут ничего сложного нет, особенно когда есть сетка, исходя из того насколько много компонентов плотно зависят от размеров, выбираю как прописывать медиа-запросы, т.е. либо запрос внутри селекторов блоков, либо селекторы внутри запроса. Как правило, используется 4-6 точек + по две на каждую основную точку, т.е. на 1px больше и на 1px меньше, но не всегда, зависит от макета. Не забываем про DPI.

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

    Потом начинается JS, т.е. наполнение интерактивом уже не средствами CSS, а именно скриптовым.

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

    Короче, как-то так… ради ответа, открыл Word и накатал этот текст. Уверен, что что-то пропустил, о чем-то не сказал, но не судите строго))

    UPD:
    Забыл сказать: про измерения скорости загрузки и скорости отрисовки. Этому стоит уделять внимание особенно в макетах со сложной композицией! Следует помнить о том, что перед отрисовкой браузеры проводят серьезный анализ DOM и каскада стилей, есть способы оптимизировать эти моменты, это важно для мобильных устройств, если у сайта нет для них отдельной версии. Это же касается и JS в части вашего ручного кода.

    UPD2:
    Ребят, я Skype указывал не для того, что вы присылали мне на него вопросы. Есть уточнения, пишем сюда или создаем новый вопрос на Тостере. Спасибо за понимание.
    Ответ написан
    4 комментария
  • Верстка с нуля: какие основные этапы работы?

    Vlad_IT
    @Vlad_IT Куратор тега Вёрстка
    Front-end разработчик
    Использую vscode+webpack+pug+scss+бэм. Из физических инструментов, основной моник: lg ultrawide 29um69g, рядом прикручен моник от ноутбука повешенный вертикально, подключенный через универсальный скаллер.

    0) Запускаю Spotify :-)

    1) Произвожу установку всех необходимых модулей для сборки. В моем случае у меня набор конфигураций для webpack (отдельные файлы для pug, scss, static и.т.д., выбираю что нужно).

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

    3) Запускаю VS Code, открываю нужную папку.

    4) Пишу размету на Pug. Пишу с БЭМ, если встречаю повторяющийся блок, то открываю файл _mixins.pug, в который пишу миксины для повторяющихся блоков, например товаров, пунктов меню, каких-то блоков и.т.д. Pug умеет делать циклы, это ускоряет сильно.

    5) Когда HTML готов, начинаю делать каркас. Если дизайн сделан по сетке, определяю контейнеры, колонки, строки в свои классы (не пишу в html тучи классов аля col-md-6, а пишу в SCSS инклуды в нужные мне блоки, типа @include make-col(2) и.т.д.).

    6) Экспортирую картинки из Avocode. Очень делается просто, указываю папку и просто кликаю экспорт и ввожу название файла и расширения. Преимущественно для иконок использую svg, если нет svg, то ищу эту иконку в интернете (дизайнеры редко рисуют иконки сами, но зато любят вставлять их не в векторе). Если иконка простая, могу сам ее в inkscape обвести, ну и если нет, то экспортирую png в размере (благо авокод это позволяет, если конечно дизайнер не вставил в исходном маленьком размере). Когда есть контакт с дизайнером, трясу его, ибо растр это плохо для иконок.

    7) Пишу стили блоков из страницы. На этом этапе можно на втором монике параллельно смотреть футураму или
    Арчера :-) Но чаще на широком монике слева браузер, справа VS Code, а на втором монике Avocode (может меняться местами с браузером). Мысленно нарезаю страницу на блоки. Для каждого блока (БЭМ) создаю отдельный scss файл (кто-то даже для элемента создает, но мне лень), из него сразу выписываю все селекторы. Иногда могу сначала выписать все селекторы со страницы (но так лучше не делать, т.к. во время работы может потребоваться изменить что-то в разметке), но чаще для одного блока выполняю этот пункт и за ним сразу выполняю пункт 8, потом для нового блока опять 7 и 8 и.т.д.

    8) Пишу css код вместе с Avocode, у него беру нужные мне параметры (а он уже подставил в них переменные), и вставляю в мой код. И параллельно сверяю со скрином макета используя вот это расширение https://chrome.google.com/webstore/detail/perfectp...

    9) Пишу адаптив. Я не могу привыкнуть к методологии mobile-first, поэтому пишу всегда сначала полную версию сайта. Я понимаю, что это чревато всякими проблемами и это типа не модно, но мне норм.

    10) Медиа-запросы пишу прямо в блоках, для каждого блока/элемента/модификатора может быть отдельный медиа-запрос. Но для начала определяю breakpoint'ы для разных экранов (чтобы их не было сотни разных), если использую Bootstrap, то беру его breakpoint'ы.

    11) Добавляю анимашки. Даже если заказчик не просил отдельно (и если не указал отдельно, что нельзя), он все равно будет доволен, а с animate.css+onscreen.js это вообще работа 10 минут. Сложные анимации обговариваю отдельно, чтобы не сделать ненужную работу.

    11) Все снова сверяю, пишу скрипты где надо. Для слайдеров в 99% случаев подходит slick (с доработками конечно, но там хорошее API), для других случаев могу написать свой.

    12) Сдаю заказчику и жду ответа сидя на тостере/пикабу.

    Это чисто мой опыт, опыт фрилансера, не знаю, как делают другие и не могу на 100% утверждать что это 100% правильный способ. Я так и не смог заставить свой конфиг webpack правильно вставлять спрайты svg.
    Надеюсь чем-то поможет мой ответ.
    Ответ написан
    7 комментариев