Профиль пользователя заблокирован сроком с 18 ноября 2017 г. и навсегда по причине: спам
  • Как не распыляясь дотащить до front-end мидл девелопера?

    EvilsInterrupt
    @EvilsInterrupt
    System programming, Reversing Engineering, C++
    1.
    так и продвижение по карьерной лестнице

    Воспользуйтесь "профайлером". Другими словами Вашим руководителем. Всегда держите руку на пульсе. Если у Вас принято брать задачи из баг-трекера, то можно в довесок договориться с руководителем о следующей практике:
    "Прошу Вас еженедельно говорить мне одну штуку из числа прошедших за неделю из-за которой Вы бы уволили меня и еще одну штуку из числа прошедших за неделю за которую Вы бы выписали премию". Ответы записывать, отсматривать после каждой новой обратной связи от руководителя и вы будете в тренде, что надо по факту, что нахрен не надо делать! При этом будете в курсе: нужны ли коллективу или вот вот пинут? То есть всегда будете знать насколько Вы реально нужны.

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

    1 и 2 дают знания и карьеру
    Ответ написан
    Комментировать
  • Как не распыляясь дотащить до front-end мидл девелопера?

    @djay
    Must have:

    - HTML5/CSS3 - знать как минимум в совершенстве
    - JavaScript, включительно ECMAScript 6-7
    - В порядке вещей - Bootstrap + Jquery
    - Grunt/Gulp, Bower
    - Знание хотя бы одного фреймворка. Сейчас более менее ходовые это Angular.js и Backbone
    - Знание системы контроля версий Git. Умение работать с GitHub/BitBucket
    - Опыт работы от 2-х лет

    Как плюс:

    - Знание Canvas, SVG, умение писать игры
    - Знание шаблонов проектирования
    - Умение покрывать код тестами

    Это и есть обобщенный набор навыков по рынку на текущий момент.
    Ответ написан
    9 комментариев
  • Какой редактор выбрать Sublime, Brackets, Atom?

    Xserber
    @Xserber
    Full-stack developer. React.js, AngularJS + NodeJS
    Раньше работал на Sublime , сейчас перешёл на Atom.
    1. Sublime выигрывает в производительности безусловно, но если верстать не порталы или интернет магазины с большой кучей каталогов, разницы малозаметно в этом.
    2. Настройки удобнее в Atom ИМХО. Не сидишь в коде и не прописываешь нужное значение для темы и тому подобное (Sublime). При желании можно и ATOM даёт такую возможность, так же полностью переписать дизайн самостоятельно.
    3.Пакеты популярные в sublime text'e тоже присутствуют в ATOM.
    4. Не надо самого начала paсkage control уставнавливать в начале.
    5. Поддержка синтаксиса в ATOM храмает, даже с дополнительными пакетами.(но это наживное)

    Какой удобней тем и пользуйтесь, рано или поздно к IDE придут большинство. Переход из Sublime text в ATOM или наоборот не составляет труда. Горячие клавиши одинаковые, миксины переписать.

    P.S. Давно слышал что ATOM хотел синхронизацию ввести пакетов, чтобы заново не устанавливать на новом рабочем месте. Может уже присутствует и это большой плюс
    Ответ написан
    Комментировать
  • Что изучить? Angular 2 или Ember 2?

    toxicmt
    @toxicmt
    CTO at hexlet.io
    Посмотрите вот это видео https://www.youtube.com/watch?v=DCeNCr2tKOI где рассказано про фреймворки.
    Ответ написан
    Комментировать
  • Книги php 2015-2016?

    Учитесь тут: getjump.me/ru-php-the-right-way
    Ответ написан
    Комментировать
  • RESTful API и MVC — что это?

    Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.
    Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).
    Как люди с появления Веба публикуют информацию в нем для потребления другими людьми, так и RESTful веб-сервисы публикуют иерархически структурированные ресурсы для потребления клиентами. Разница только в представлении - для людей это plaintext/HTML, для автоматических агентов - это JSON/XML/прочие форматы, которые удобно обрабатывать.
    Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.
    Важно понимать, что "ресурс" это обычно некоторая сущность, "существительное". Как правильно заметил Антон Жуков , ресурс /getItems хоть и может существовать в принципе, говорит о неудачно спроектированном API (действие представлено как ресурс).

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

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

    Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

    Смысл использования REST в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

    Ответ длинноват, но как короче объяснить, чтобы не исказить понимание, не представляю. Если что непонятно - спрашивайте.
    Ответ написан
    7 комментариев
  • Стоит ли идти изучать Node.Js, или стоит подкрепить знания по JS??

    Taraflex
    @Taraflex
    Ищу работу. Контакты в профиле.

    Так же сверстал сайт-портфолио( прошу оценить - )

    rar архив на яндекс диске?
    5438988_m.png
    Воспользуйтесь для таких целей https://pages.github.com/
    Ответ написан
    3 комментария
  • Путь от junior к web backend developer?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) учим C# + алгоритмизацию (вы как минимум должны знать что происходит при вставке в хэш-таблицу и хотя бы примерно понимать что такое куча, на бэкэнде структуры данных знать очень полезно)
    2) учим ООП (читаем паралельно Фаулеров, Кентов Бэков, Бобов Мартинов)
    3) постепенно берем ASP MVC и вперед к свершениям.
    4) асинхронное/паралельное программирование

    Каждый пункт сдобрим практикой
    Ответ написан
    Комментировать
  • Есть ли смысл учить yii2 без знания JS?

    nepritimov_m
    @nepritimov_m
    Frontend dev.
    Если ты будешь один разрабатывать какой-то проект, то JS изучить надо будет. Но в любом случае, изучение php-фреймворка пойдет на пользу. Хорошо изучив концепцию паттерна MVC и сам Yii2, сможешь найти работу backend-разработчиком.
    Вывод такой: учишь и то и другое одновременно. Уделяй Yii 2/3 времени, а JS - 1/3 и будет норм)
    Ответ написан
    Комментировать
  • Есть ли смысл учить yii2 без знания JS?

    alexey-m-ukolov
    @alexey-m-ukolov Куратор тега JavaScript
    Стоит ли учить php-фреймворк без знания другого языка? Да, сложный вопрос, нужно посоветоваться с сообществом...
    Ответ написан
    Комментировать
  • Как документировать существующее решение?

    eduardtibet
    @eduardtibet
    Technical Writer / Documentation Engineer
    Чтобы понять, какие решение вам надо, вам надо задать себе следующие вопросы:
    1. Предполагается ли документацию выносить наружу?
    2. В каких выходных форматах вы хотите поставлять документацию? Предполагается ли печатка (как класс)?
    3. Предполагается ли многоуровневая документация (т.е., например, несколько модулей для клиента А, несколько для клиента Б и т.п.)?
    4. Надо ли документировать API (руками или автоматически)?
    5. Кто будет осуществлять поддержку всего этого хозяйства?
    6. Какой объем (примерно) сейчас и какой объем будет после года?
    7. Надо ли хранить версионность всего этого добра?

    Есть еще вопросы, но на текущий момент пока хватит :)
    Ответ написан
    Комментировать
  • Как документировать существующее решение?

    @Vusluk
    Front-End разработчик; электронщик
    Как вариант, поднять внутреннюю wiki. По опыту скажу, лично мне, как программисту удобней всего было работать именно с wiki.
    Ответ написан
    1 комментарий
  • Как эффективно изучать php?

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

    @deliro
    SSH - та же консоль, только удалённая. Знать там нужно только основные команды nano cat ls ln rm cp mv mkdir и т.п.
    Обязательно прочитай мануал к virtualenv. Можно и без него, если джанго-приложение на сервере одно, но лучше с ним. Удобнее.
    С nginx'ом особо колдовать не нужно, вот тут написано, как его настроить.
    HTTP-серверов для джанго основных два: Gunicorn и uWSGI.

    На дев-сервере вообще ничего не нужно. В джанго уже есть сервер (runserver) и база SQLite, которую устанавливать тоже не нужно.

    Никаких книг тут не нужно, достаточно почитать пару Getting Started к используемым технологиям.
    Ответ написан
    5 комментариев
  • Где посмотреть примеры документирования разработки сайта?

    eduardtibet
    @eduardtibet
    Technical Writer / Documentation Engineer
    Вы не обозначили самое главное: ДЛЯ ЧЕГО вам надо писать документацию?

    Возможные варианты:
    1. "Для галочки" - чтобы сдать заказчику.
    2. Для уменьшения стоимости владения - например, чтобы новые/внешние разработчики не спрашивали "как это работает" и не отвлекали.
    3. Для облегчения жизни себе - например, чтобы новую версию можно было делать на основе старой и ничего не забылось со временем.
    4. Еще варианты....

    Это САМЫЕ главные вопросы. Ответьте на них - потом можно будет думать дальше :)
    Ответ написан
    6 комментариев
  • Как понять структуру laravel?

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

    Фасад - это способ к некому классу обратиться как к статическому. Для этого при "создании" (точнее регистрации) фасада регистрируется код создания экземпляра класса и дальше при вызове SomeClass::method() фреймворк создает класс SomeClass при помощи этого кода и вызывает метод method(). laravel.su/docs/5.0/facades

    Сервис-провайдер - это класс, который осуществляет инициализацию некоторой части приложения Laravel - регистрацию фасадов, папки вьюх, конфигов, в общем, всего подобного. Хватило бы одного сервис-провайдера, но их много, потому что модуль, пакет или логическую часть приложения удобнее инициализировать в отдельном классе, а не дописывать все в существующий. laravel.su/docs/5.0/providers

    Сервис-контейнер Laravel, при помощи которого (а не при помощи оператора new) создаются все классы во фреймворке, по сути не отличается от такого же фальконовского: laravel.su/docs/5.0/container . Он нужен для реализации DI, т.е. при создании некоторого класса, например контроллера, проходить по аргументам методов, смотреть, какие там подаются классы на вход, создавать экземпляры этих классов и собственно подавать их на вход.
    Ответ написан
    1 комментарий
  • Ruby, Python или NodeJS для сервиса?

    k12th
    @k12th
    console.log(`You're pulling my leg, right?`);
    Смысла нет делать это одним сервисом. Это разные задачи, пишите два отдельных приложения, им даже не надо общаться друг с другом, достаточно просто читать и писать в одну и ту же БД. Сервис аналитики можно вообще рзаместить на отдельном серваке и даже у другого хостера.
    Ответ написан
    Комментировать
  • Стоит ли изучать Yii 1?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    для создания - yii2
    Yii1 разве что, если собираетесь поддерживать старые проекты.
    Ответ написан
    Комментировать
  • Стоит ли использовать ооп?

    vt4a2h
    @vt4a2h
    Senior software engineer (C++/Qt/boost)
    Русский язык сначала освойте. PHP вам рановато.
    Ответ написан
    3 комментария