• Как прокачаться и научиться языку программирования\аналитики R?

    Absolem
    @Absolem
    Я качаюсь на DataCamp на бесплатных курсах. Начинал с курса Try R от CodeSchool.com.
    Дальше Специализация Data Science на coursera.org, можно всё проходить бесплатно.
    Ответ написан
    Комментировать
  • На каком ЯП проще начать удаленную работу или фриланс?

    delch
    @delch
    Frontend developer
    Веб сейчас наиболее выгоден, так что ruby on rails или python
    Ответ написан
    Комментировать
  • Какие самые реальные и действенные проекты\работы\фриланс для python-программиста?

    voidnugget
    @voidnugget
    Программист-прагматик
    Пишу на питоне ещё с 15 лет (2.4+)... ненавижу его runtime и архитектуру. Язык хороший - реализация никакущая. Ну да его синтаксис достаточно упрощён, но и за синтаксический сахар приходится платить сложностями отладки и поддержки.

    Сейчас же почти все известные мне конторы не используют питон в продакшенах с более-менее высокой нагрузкой. Яндекс тому пример. Чаще питон используется для решения прикладных задач администрирования, так как это делается, к примеру, в SaltStack. Все дружно слезают с питона, РНР и рельсов на Golang, Java/Scala, и иногда даже Groovy - производительность выше в десятки раз, и managed runtime на много стабильнее. Правда в случае с JVM очень сильно раздувается куча в виду избыточности объектной модели (оператву жрёт как дурное, а я байтики считать привык). Сейчас это должно лечится с помощью Project Graal и Truffle, правда пока до этого дошёл только jRuby, который тоже в пару десятков раз быстрее Ruby. По идее и Groovy тоже должен переползти как-то ... Вот про jyton ничего не знаю.

    Много моих знакомых слезло на Golang с Ruby и Питона.
    Стоит попробовать - он достаточно простой и идиоматичный, вот рефлексию стоит обходить стороной - она очень медленная, впрочем как и везде. Работу может и не найдёте сразу, но после реализации пары простых проектов будет проще предлагать в качестве целевой платформы.

    Фрилансить с питоном начать можно, но очень желательно опробовать ещё хотя бы пару окружений и фреймворков типа Groovy Grails, или Typesafe Stack. Сейчас требования рынка возросли в пару раз за последние два года - нужны ассинхронности/многопоточности, push-нотификации в мобильные приложения и по вэбсокетам/комету. И это всё с богатыми js-фронтендами на всяких там Angular'ах и React'ах. Естественно можно крутить костыли типа Celery / Gearmand / Beanstalk / RabidMQ, но накладные расходы на коммуникацию слишком большие :( Компилируемые языки со своими Managed Runtime'ами позволяют строить монолитные приложения в которых подобные решения избыточны в рамках одной и той же машины, а если это куча нод в кластере то нужно мерить/думать.

    Django сейчас сложно поддерживать так как он достаточно сильно развился за последние 3 года, и я очень сомневаюсь что сохранится совместимость новых версий со старыми.

    А вот с pyramid (pylons) и SQLAlchemy можно строить достаточно хорошие приложения. У них есть enterprise поддержка и соответствующие гарантии.

    Типовые задачи на питоне:
    - написать какой-то мелкий скрипт с Gui на PyQT / Pyside для какой-то аналитики и отрисовки графиков, иногда попадаются задачки с gstreamer'ом
    - написать какое-то простое RESTful CRUD приложение, в стиле "одна табличка БД - один контролеер", это конечно же тонна копипасты и мне больше нравятся DataMapper'ы по типу TastyPie. Иногда люди хотят чистого Tornado или Flask'a, так как им не нравится overhead в джанге и pylons.
    - написать скрипты для деплоя чего-то, обычно люди не знают про SaltStack.

    В плане архитектуры питонистам чужды различные SOA с CQRS-ES'ом, потому что сам компилятор не располагает. Хотя её достаточно просто поддерживать.

    Проблема всех проектов на Node.js / Python / Ruby это отсутствие долгосрочной поддержки библиотек и фреймворков - часто ломается обратная совместимость, и нужно постоянно следить за состоянием всех зависимостей. Опять же нужен TDD/BDD для того что это всё хорошо контролировать. Тестируешь руками - себя не уважаешь.

    Ну и вроде всё ...
    p.s. я опубликую на хабре статью сегодня-завтра "Freelance - you're doing it wrong" там поделюсь опытом работы и основными организационными проблемами в рамках удалённой работы и фриланса, покажу разницу между ними.
    Ответ написан
    6 комментариев
  • Зачем нужны таск менеджеры GULP и GRUNT?

    Мне кажется тут не хватает образного примера:

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

    Вот и сказочке конец, а кто слушал, тот и gulp.

    Простите - пятница.
    Ответ написан
    Комментировать
  • Как лучше учить английский?

    @nuubie
    Начал учить в 24 года английский с абсолютного "0", т.к. в школе/универе учил только немецкий, в 28 лет сдал IELTS на 7.0.

    Несколько советов:
    1. Рекомендую учить английский только по учебникам на английском. Много времени потратил впустую на попытки выучить по Драгункиным, Илонам Давыдовым, Бонкам и т.п... Лучший вариант - взять самые простые уровни Headway и Cutting Edge и последовательно их проходить .
    2. Нужен наставник, чем выше левел, тем более опытный. Upper-Intermediate - Advanced нужен профессиональный преподаватель, желательно сам прошедший хоть какой-то международный экзамен или сертификацию.
    3. Практика - регулярное общение с носителями языка очень быстро убирает т.н. "языковой барьер" даже если сам два слова не можешь связать.
    4. Чтобы грамотно говорить и писать - надо зубарить грамматику регулярно. Лучшие учебники по грамматике: English Grammar in Use и MyGrammarLab, остальное выбирайте на свой вкус. Кроме грамматики есть еще куча нюансов в зависимости от стиля общения/письма: formal/semiformal/informal, в зависимости от страны British/American/Australian English.
    5. Регулярность занятий: выделял 20 - 30 часов еженедельно для самостоятельных занятий, когда стало больше практики на работе - достаточно 4 - 6 часов на самостоятельное изучение и 4 - 6 часов на курсы на работе+speaking club с носителями языка.
    6. Очень помогает понять свои слабые стороны и адекватно оценить текущий уровень сдача экзаменов IELTS, TOEFL.
    7. Многое зависит от целей которые вы перед собой ставите, просто поехать пообщаться в другой стране достаточно с уровнем pre-intermediate+язык жестов :) Если для карьеры - то лучше сразу брать курсы Market Leader или Business Result, English for IT pros и т.д. Во-первых, лексики нужной быстрее наберетесь, во-вторых, материал будет понятней, т.к. тесно связан с вашими интересами.
    8. Есть масса аудиоподкастов и видеоуроков, мне нравятся: EnglishBusiness Pod, ESL Pod, EnglishVid, openlanguage.com
    Ответ написан
    3 комментария
  • Какой софт использовать для верстки / программирования (Front-end)?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    Проектирование — Balsamiq Mockups (ну и MS Word, куда же без него:)
    Нарезка — Fireworks (Photoshop для коррекции полученных макетов)
    Иконки — ArtIcons (не идеал, просто купил когда-то) или любой редактор для PNG + любой конвертер
    SVG — Illustrator и Inskape
    Пипетка (просто пипетка, а не комбайн) — EYE3 (вариантов масса)
    Код — Sublime (посматриваю в сторону WebStorm), иногда Notepad++, иногда Excel для подготовки массивов данных
    Локальный сервер — использовал из-за простоты установки Denwer, перехожу на Node.js
    FTP клиент — Filezilla
    Быстрая проверка на iPad, iPhone (iPod) — Electric Mobile Studio
    Ответ написан
    3 комментария
  • Что изучать, на что тратить свободное время, чтобы в будущем стать востребованным программистом с нормальным заработком?

    lexxpavlov
    @lexxpavlov
    Программист, преподаватель
    Ответ на вопрос будет сильно зависеть от того, в каком направлении вы думаете развиваться.
    Будет ли это сетевое программирование? Тогда это си, в основном.
    Может быть, веб-программирование? Тогда тут могут быть php, javascript, python, ruby.
    Захотите разрабатывать программы на десктоп? Вам нужны c# или java.
    На мобильные платформы? тогда java и objective c (плюс swift).
    Или податься в разработку игр? Тогда либо c++, либо с# (для Юнити - наверное, самой популярной платформе).
    Хотите экзотики? Приглядитесь к функциональным языкам - Erlang и Haskell.
    Разработка железа и драйверов для железа? тогда си (без плюсов) и ассемблер.
    Определитесь, что вы хотите, потому что всё объять не получится. Выберите один (или два) направления и добейтесь хорошего уровня в нём. А потом вам будет уже легче двигаться дальше.

    Мой совет - попробуйте изучать C# или Java (они во многом похожи) для софта, или Javascript и php/python для веб-приложений и сайтов.

    Добавлю, что очень правильный совет дал @tsarevfs - помимо языка программирования, хороший программист должен знать несколько инструментов - и в первую очередь, это система контроля версий, например, git. Плюс юнит-тестирование (хотя это можно начать изучать позже, через годик-два). Плюс - нужно хорошо знать свою IDE, в которой работаете; не вздумайте работать в блокнотиках!

    Ещё помимо практики нужно знать теорию - читайте Макконнелла, Фаулера, Мартина, Бека.
    Подпишитесь на хабре на пару десятков хабов и регулярно читайте всё подряд. Через годик ваш уровень понимания статей сильно вырастет.

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

    UPD. Важное дополнение из обсуждения в комментариях (спасибо @Argentum88 @Deerenaros )
    Чтобы стать профессионалом и "востребованным программистом с нормальным заработком", нужно очень хорошо понимать внутреннее устройство тех систем (платформ, фреймворков), на которых идёт работа.
    Для этого нужно заглядывать вглубь. Изучив различные мейнстрим-инструменты, посмотреть на аналогичные менее популярные системы. Изучать исходный код используемых open-source библиотек. Написать свою подобную систему. Для web - написать свою CMS (хотя бы базовую). Для десктоп-программ - попробовать программировать без навороченных библиотек, которые делают рутинную работу за программиста. Для разработчика игр - сделать простую игру на базовом инструментарии платформы, где всё придётся делать своими руками.
    Всё это даст возможность проникнуться, почему всё делается именно так, даст понимание взаимосвязей разных частей программы.
    А потом, осознав это, выбрать один из уже готовых инструментов, и продолжать писать на нём, уже обладая более глубоким его пониманием.
    Ответ написан
    21 комментарий
  • Стоит ли использовать малоизвестные технологии при разработке, чтобы "привязать" к себе заказчика?

    iiil
    @iiil
    Инженер и вэб-дизайнер, рисую.
    Заказчика лучше удерживать другими способами, например, качеством работы.
    По мне так большинство и так достаточно ленивы, чтобы менять исполнителей. Это же каждый раз риск, трата времени.
    Кроме того, малоизвестные технологии скорее всего и развиваются медленно, имеют риск умереть. Представляете, как будете оправдываться перед заказчиком, почему не можете сделать ту или иную фишку, которая есть уже у всех его конкурентов. Что Вы ему скажете?
    Ответ написан
    Комментировать
  • Стоит ли использовать малоизвестные технологии при разработке, чтобы "привязать" к себе заказчика?

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

    Помимо этого есть вопрос репутации. Довольный клиент рассказывает 1-2 людям. Недовольным - 10рым.
    Это относится к вообще любым серым приемам. Можно и исходный код зашифровать, что уж стесняться.
    Ответ написан
    Комментировать
  • Что сейчас перспективней в мире Web технологий?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Холивара ради, а почему PHP сразу нет?

    p.s. Вообще не вижу смысла париться, перейти из одного языка в другой не так уж и много времени занимает. В Ruby может будет тяжелее после .NET, но тоже довольно быстро можно привыкнуть.
    Ответ написан
    3 комментария
  • Сертификация PHP программиста. Что выбрать? И стоит ли вообще?

    akubintsev
    @akubintsev
    Опытный backend разработчик
    Сертификации по PHP никакой роли не играют вообще. Тем более, что единственная более-менее известная это ZCE.
    Был случай на одной работе, когда было 2 хороших кандидата, один с ZCE, другой без. Взяли того, что без сертификата. Чисто из личных предпочтений видимо.
    Ответ написан
    Комментировать
  • Кто начинал программировать с 20-ти лет и старше?

    @Mintormo
    1. Народ, да вы уже с дуба упали. То были обсуждения "А не поздно ли начинать в 40?", потом в 30, сейчас 20. Скоро с детсада начнем? Никогда не поздно. Было бы желание. С этим часто проблемы бывают.

    2.
    Как вы думаете стоит ли этим заниматься или лучше заняться чем нибудь другим?

    Это ты только сам себе можешь ответить. Попробуй и узнаешь. Если будет интересно то можно попробовать. Нет - поищи что-то другое.
    Ответ написан
    Комментировать
  • Как практиковаться на Ruby / RoR ?

    Freika
    @Freika
    Senior Ruby on Rails developer
    В книге есть практика на протяжении 14 глав, кажется. Параллельно можно начать реализовывать свой проект. Я сделал агрегатор блогов(парсит рсс раз в 30 минут) еще до прочтения этой книги, сейчас закончил перенос несложного сайта на Рельсы, а когда взглянул в код агрегатора, заплакал кровавыми слезами. Буду переписывать.
    Одним словом, если есть идеи, беритесь за них. Потом десять раз переделаете, улучшите и обновите, и будет вам практический опыт.
    Ответ написан
    1 комментарий
  • В удаленный репозиторий git случайно попал ненужный файл, как удалить?

    jcmvbkbc
    @jcmvbkbc
    "I'm here to consult you" © Dogbert
    Как удалить?

    В зависимости от того, хотите ли вы, чтобы файл остался в истории или нет:

    git rm -f <имя файла>
    git commit
    git push
    -- удалить из HEAD, но оставить в истории

    git rebase -i <ревизия в которой файл был добавлен>~1
    <пометить самый первый коммит для редактирования заменив peek на e>
    git rm -f <имя файла>
    git commit --amend
    git rebase --continue
    git push
    -- удалить из истории совсем. Если добавление было в последнем коммите, то команды git rebase можно опустить.
    Ответ написан
    9 комментариев
  • В проектах начал использовать различные СУБД. Какие есть альтернативы phpMyAdmin?

    @vitaliycto
    Если есть внешний доступ к мускулу, очень рекомендую dbForge Studio (есть бесплатная версия).
    Поможет в составлении и оптимизации сложных запросов, синхронизирует структуру и данные на разных серверах и много чего ещё.
    Ответ написан
    Комментировать
  • Как организовать защиту от парсинга сайта?

    Написал довольно много различных парсеров и автоматизаций веб разной сложности, и могу сказать, что единственный вариант - это не публиковать информацию вообще. Думаю следующее поможет отбить желание парсить сайт или как минимум повысит стоимость разработки\поддержки парсера:
    1. Система мониторинга поведения пользователя (движение мышки, координаты нажатия на кнопки и т.п.) для того чтобы вычислять ботов.
    2. Не использовать Id и name или другие атрибуты, по которым можно вычислить контент.
    3. Обфусцировать СSS и делать имена классов динамическими.
    4. Динамически добавлять различный мусор в разметку.
    5. Использовать веб-фреймворк, и не светить методы наружу.
    6. Использовать капчу, от разных вендоров и с динамически генерируемым url, причём загружать её так, чтобы её нельзя было вытащить из кэша браузера (от перехвата запроса это не спасёт, но жизнь автоматизаторам подпортит).
    7. Переодически менять вёрстку.

    Загружать контент через Ajax я бы не рекомендовал: перехватить реквест от браузера не такая уж большая проблема, зато сразу сужается область поиска контента.
    Ответ написан
    Комментировать
  • Как организовать защиту от парсинга сайта?

    @starosta6123
    1. Сайт изначально предназначен для публикации, то есть он открыт.
    2. Если вы не хотите чтобы информация была открыта, не публикуйте.

    Из 1 пункта следует, что нет достаточных средств для защиты от парсеров.
    Вопрос только в том, на сколько вы готовы и можете усложнить жизнь для парсеров.
    А нужно ли это? Может вы - "неуловимый Джо"?
    Все что может прочитать и распознать человек (а ведь именно для людей и делается сайт?) может быть воспроизведено. В части, где парсинг может быть автоматизирован, он будет автоматизирован.
    Сейчас существуют мощные парсеры Яндекса и Гугла. Если они ваш сайт не смогут разобрать, то и в индексе его не будет, значит полезная информация не дойдет до конечного пользователя.
    А тот, кто захочет, ее скопирует, если информация очень нужна. Если даже вы представите в виде мозаики из картинок и кусков, даже если зашифруете, но информация на экране должна все равно быть читабельной, а значит простой принтскрин и распознавание в FineReader будет быстрее, чем вы напишите защиту от него...

    Бросьте это занятие!

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

    И еще раз бросьте это!

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

    Последний совет: бросьте это!

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

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

    Извините, за столь большой сумбур!

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

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

    3. Блокировка по IP не прокатит, так как могут пострадать реальные люди, достаточно применять динамический IP.

    А вообще, если хотите спастись от простых парсеров, то комплекс мер может помочь. Так же могу натолкнуть на идею, того, что парсеры обычно очень активны, и по количеству запросов с одного IP, по USER_AGENT, и другим меткам, а так же по отсутствию javascript, по обработке тега <МЕТА> redirekt.info/article/redirekt-na-html-s-zaderzhko... (отложенный редирект) и другим признакам. Можно запихнуть скрытую картинку (style="display: none"), большинство парсеров ее могут дернуть (зависит от настроек).

    В общем, можно поставить задачу в другом ключе: "Расстановка ловушек для парсеров". То есть ловить на том, чего обычные люди и браузеры делать не будут. Например, заполнять "скрытое поле пароль". Удачные ловушки дадут вам возможность выявить подставных, но лучше делать несколько проверок, а то можно и реального пользователя забанить. А я бы не стал банить, а сливал бы немного или частично измененную инфу. Эта инфа может стать маркером для выявления того, кто действительно желает с вас "слить".

    Все, удачи!
    Ответ написан
    4 комментария