• Как поднять себе зарплату?

    @evgeniy_lm
    Говорят, что хороший специалист не тот кто знает как сделать, а тот кто знает почему он делать не должен.
    "Доля участия" увеличилась не сама по себе. Сначала возник некий объем работы как следствие возник вопрос кто этот объем возьмет на себя. Ты не стал задать логичные вопросы типа "А почему я? Мне, что больше делать нечего?", "А как увеличение объема работы скажется на увеличении объема зарплаты?", а взял под козырек и побежал батрачить. Халявная рабсила это голубая мечта любого руководства.
    Теперь у тебя только один вариант решения проблемы - смена работы. Причем зарплата на новой работе не обязательно должна быть выше. Главное чтобы на новом месте ты не совершал старых ошибок и помнил что увеличение объема работы всегда влечет увеличение размера зарплаты. Не увеличивается зарплата - не увеличивается объем работы
    Ответ написан
    Комментировать
  • На чём лучше вести локальную разработку?

    boramod
    @boramod
    Упрощенно.

    Вагрант — система управлением конфигурацией конкретной машины.
    Докер — запуск изолированных процессов на машине.

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

    В терминологии Докера есть Images и Containers.
    Image — образ, шаблон, на основе которого запускается Container.
    Image строится на основе какого-либо базового образа ОС.

    Container — сервис, запущенный и построенный на базе Image.

    Таким образом, вы можете построить несколько образов, например, образ для Nginx, образ для PHP, образ для MySQL. Вдобавок, вы можете построить несколько образо, для каждой желаемой версии PHP, MySQL и т.п.

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

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

    Оба инструмента хороши. Но у каждого свое назначение.

    Vagrant — великолепный инструмент для конфигурации удаленных машин с нуля, VDS/VPS и т.п.
    Docker — великолепный инструмент для быстрого развертывания/переконфигурации рабочего окружения, практически без изменения системы, на которую он устанавливается.
    Ответ написан
    6 комментариев
  • Что такое асинхронное копирование файлов?

    @Mercury13
    Программист на «си с крестами» и не только
    В WinAPI асинхронное копирование файлов — это использование так называемого «асинхронного ввода-вывода» (Overlapped I/O), механизма, который не поднимает новых потоков (по крайней мере явно), но позволяет параллельно с вводом-выводом делать что-то другое. В данном случае — читать и записывать одновременно.

    Что это даёт?
    1. Уменьшает простои программы и этим ускоряет копирование.
    2. Если копирование в пределах одного механического AHCI-диска (из каталога в каталог, с раздела на раздел)— это позволяет оптимизировать маршруты головки на уровне драйвера или контроллера.
    3. Если копирование между разными накопителями — накопители будут действовать параллельно.
    Ответ написан
    Комментировать
  • В чем преимущества *nix, linux перед windows (для веб разработчика)?

    proshin
    @proshin
    Java web developer
    Я бы добавил в список преимуществ линукса вот что:
    - в линуксе везде по умолчанию используется UTF-8, а в винде - CP1251
    - в линуксе файлы с расширениями 1.JPG и 1.jpg будут "указывать" на разные файлы, для винды это один и тот же файл (при работе с Git в винде это иногда напрягает - видишь JPG, хочешь переименовать в jpg, а фига).
    - по моим личным наблюдениям файловая система в линуксе быстрее работает, чем в винде (Ext4 против NTFS; один и тот же жесткий диск).
    - ну и как бонус: в линуксе ты не можешь "по-быстрому погамать несколько часов пока проект компилится" - но это уже мелочи.
    В конце же концов, нужно выбирать ту систему, где удобно работать - сейчас любую софтину можно запустить на любой ОС.
    Ответ написан
    2 комментария
  • Есть ли сервисы для практики в создании sql-запросов?

    @Beriger
    Ответ написан
    Комментировать
  • Для чего нужен Docker?

    @spotifi
    Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

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

    Это почти виртуальная машина. Почти, да не совсем.


    Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

    Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

    С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

    Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

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

    Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

    Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

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

    Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

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

    Зачем это используется?

    Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

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

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

    Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

    Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

    До этого люди мучались, придумывали хитрые инсталяторы...

    Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

    Другими словами:
    • Докер-контейнер нужно использовать для отладки.
    • Тот же Докер-контейнер нужно использовать и на сервере.


    Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

    Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

    Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

    UPD:

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

    Разработчик отдает весь свой результат в систему CI (обычно через git)
    CI на каждый новый коммит делает с помощью Docker образ для тестирования.
    Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
    Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

    То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
    А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

    Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).
    Ответ написан
    18 комментариев
  • Для чего нужен Docker?

    @viiy
    Linux сисадмин \ DevOps
    Представьте что нет никакой ложки докера.

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

    2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

    3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

    4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

    Все запущенные процессы Docker помещает в изолированную среду процессов, файловой системы и сетевого стека. Есть много особенностей по работе с Docker, т.к он предполагает, что в одном контейнере вы запускаете один процесс. Если вам нужно запустить целый набор демоном, тут появляются проблемы, нужно писать шелл-скрипт, который все это поднимет в контейнере. Так же есть особенности по сети, файловой системе. Для кого то Docker спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.
    Ответ написан
    15 комментариев
  • В чем преимущества *nix, linux перед windows (для веб разработчика)?

    selivanov_pavel
    @selivanov_pavel
    Linux admin
    Виртуализация на современных процах работает быстро, необходимости работать в такой же системе, как на сервере, нету. Vagrant/Virtualbox подволяют разрабатывать под нужную систему, оставаясь в своей привычной. Работать надо в системе, которая позволяет эффективно выполнять требуемые задачи, не отвлекаясь на её обслуживание, обновления, починку и т. д.

    ИМХО существующие ОС в этом плане можно выстроить в такой порядке:
    1. MacOS
    2. Windows
    3. Linux

    З.Ы. Сам на десктопе использую Linux, но исключительно потому, что очень не люблю слежение за пользователем и серьёзно отношусь к приватности своих данных. Иначе давно использовал бы MacOS.
    Ответ написан
    Комментировать
  • Как разработать GUI на C++?

    На голом WinAPI рисовать свои контролы для красивого интерфейса - та еще проблема. Придется писать ООЧЕНЬ много кода. Из минимальных прослоек к WinAPI можно использовать WTL и MFC.
    Для MFC есть ряд платных библиотек, упрощающий разработку UI и уже имеющие набор сильно кастомизированных контролов. Это, например, Codejock и BCGSoft.
    Если все таки отказаться от низкоуровневого использования WinAPI то нестандартный пользовательский интерфейс можно реализовать с помощью WPF (на .NET), Sciter (UI движок, использующий HTML/CSS для отображения. Написан на с++, легко интерируется с С++, кроссплатформенный, бесплатный при использовании бинарников), QT(c++, есть язык разметки интерфейса QML).
    Да, кстати, использование DirectX, OpenGL отношения к WinAPI не имеет.
    Ответ написан
    2 комментария
  • Как уйти с распутья технологий?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    27cm
    @27cm
    TODO: Написать статус
    Комментировать
  • Парсим/грабим веб-страницы без мусора?

    leahch
    @leahch
    3D специалист. Dолго, Dорого, Dерьмово.
    Конечно есть - lxml.de/lxmlhtml.html#cleaning-up-html
    Ну и уже из очищенного можно выделять что нужно.
    Да, забирать лучше библиотекой requests - docs.python-requests.org/en/master
    Ответ написан
    Комментировать
  • Существует ли способ для Chrome позволяющее на определенные часы блокировать web-ресурсы по ссылкам и ip-адресам?

    Jump
    @Jump
    Системный администратор со стажем.
    Cмотрите решения для Children-control, есть встроенные в Windows, есть более богатые возможностями в антивирусах типа касперского.
    Пароль ставьте длинный чтобы забыть - бумажку с паролем закопайте в лесу.
    Но я не думаю что такими мерами можно победить ра.пи...ство.
    Поэтому лучше не маяться дурью, а просто работать. ;)
    Ответ написан
    2 комментария
  • Установщик зависимостей проекта для Python 3?

    sim3x
    @sim3x
    $ sudo apt-get install python-dev python-pip virtualenvwrapper
    $ mkvirtualenv virtname -p /usr/bin/python3
    (virtname) $ pip install -r requirements.txt


    inline tag code
    Ответ написан
    4 комментария
  • Есть сайты для общения начинающих программистов, или что-то подобное?

    27cm
    @27cm
    TODO: Написать статус
    Список русскоязычных IT чатов (Gitter, Slack, Skype):
    https://github.com/mr-mig/ru-it-chats
    Ответ написан
    Комментировать
  • Два пароля к zip архиву. Возможно ли?

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

    rpsv
    @rpsv
    делай либо хорошо, либо никак
    Как по мне, то картинка такая:
    • Дизайнер - рисовака;
    • Верстальшик - конвертер макета в HTML код;
    • Веб-дизайнер - дизайнер + верстальщик;
    • Front-end разработчик - верстальщик + много еще чего.

    А термин веб-программирование может означать:
    • Front-end
    • Back-end
    • Full-stack

    Так что как по мне, хренова-то курсы расписаны.
    Ответ написан
    4 комментария