• Хватает ли 13 дюймового экрана для веб-разработки?

    pOmelchenko
    @pOmelchenko
    php-developer
    Нет не хватит. Быстро внести правки - да. Разрабатывать имея только этот экран - боль и страдание даже для бэк-энда. Я сейчас всерьез задумываюсь о покупке домой 1-2 мониторов для работы.
    Ответ написан
    Комментировать
  • Хватает ли 13 дюймового экрана для веб-разработки?

    @sir_Maverick
    Вам зачем 13"?
    Чтобы таскать с собой и работать на корточках сидя? Тогда тут вопрос не в удобстве работы, а в удобстве переноса.
    Чтобы таскать с собой на встречи и выглядеть круто или просто таскать с собой и выглядеть круто? Какая тогда разница, насколько в нем удобно работать.
    Если вам вообще не таскать с собой, или только с работы домой, или из спальни на кухню - тогда 15". Или 17". Или 13" и монитор.
    Обычно 11" - 14" берут для поездок или работы там, где самому негде зад пристроить.
    Ну или чтобы заказчик обратил внимание на "нубук для бизнеса".
    Ответ написан
    2 комментария
  • Появятся ли вакансии, требующие знания экосистемы vue.js в 2017?

    bosenok
    @bosenok
    Frontend Developer
    Вакансии (если их можно так назвать) уже есть. Я начал смотреть в сторону Vue еще пару лет назад и сейчас он активно внедряется во все проекты, которыми я занимаюсь. Другое дело в том что я не искал человека, который знает Vue. В моей команде есть фронт-джун и ему была поставлена задача осваивать Vue. Он кстати долго терзался на тему зачем ему Vue, если во всех вакансиях Angular и React, потому что год назад о вакансиях с Vue даже и речи не шло.
    Вот только я забраковал React (по причине разметки в коде и тормознутости лицокниги) и забраковал Angular по причине его монструозности (а уж после того как вышел Angular 2 - на который мигрировать с первого вообще никакой возможности нет - я только утвердился в своем решении). Так что мои проекты переходили на Vue (как на первую стоящую технологию) со старого доброго jQuery.
    Ответ написан
    6 комментариев
  • Как реализовать CRUD правильно?

    xpert13
    @xpert13
    Full Stack Developer
    В HTML файле нельзя использовать PHP код, измените расширение файла на PHP.

    P.S. Поищите другие уроки, те которые учат смешивать HTML и PHP код плохие.
    Ответ написан
    1 комментарий
  • Если проверять id на наличие букв можно ли обезопасить себя от sql injection?

    Будьте проще $idq = intval($_GET ['id']);
    Ответ написан
    Комментировать
  • Как организовать безопасность админки?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Открою тайну: через .htaccess можно прописывать октеты и подсети!
    Вы можете прописать (точка в конце - ОБЯЗАТЕЛЬНА!): xxx.xxx.xxx.
    или xxx.xxx.xxx.0/24 и т.д.
    И таким образом разрешить доступ только для своей подсети.

    И вопрос: откуда "предприимчивые граждане" знают ссылку к Вашей админке?)
    Ответ написан
    2 комментария
  • Русскоязычный форум Symfony?

    Roman_Romanov
    @Roman_Romanov
    symfony
    Ответ написан
    Комментировать
  • "Сильные" книги по Symfony и архитектуре приложений?

    by25
    @by25
    Веб-разработчик
    1. Мэтт Зандстра "PHP: объекты, шаблоны и методики программирования" - Врубиться в ООП
    2. Эрик Фримэн и ко "Паттерны проектирования" (Head First) - Влюбиться в ООП
    3. Эрик Эванс "Предметно-ориентированное проектирование" - научиться проектировать сложные системы
    4. Крэг Ларман "Применение UML 2.0 и шаблонов проектирования" - про проектирование, глубокое понимание ООП
    Ответ написан
    Комментировать
  • Какую выбрать легкую, но безопасную CMS?

    @danforth
    Wordpress - дырявая, если не обновлять, и ставить все плагины без разбора.
    Простенький сайт - лучше написать самому на каком-либо фреймворке. Можете взять что-то вроде OctoberCMS (выбрал по запросу CMS based on framework). Они обычно идут с самым минимальным функционалом.
    Защитить админку можно разными путями, вплоть от создания .htaccess файла с запретом доступа по IP, и до более продвинутых методов.

    В вашем случае WP не плохой вариант.
    Ответ написан
    2 комментария
  • С помощью чего писать тесты для сайта?

    @hubramubr
    Не пишешь тесты - ты плохой программист?
    Это от задачи зависит. Автоматизированное тестирование - это вещь. Но на недорогих проектах обходятся без этого.

    Есть тесты серверной части, есть тесты JS, есть тесты функциональные, есть юнит-тестирование. Они все пишутся по разному и на разном.

    Ну, например, Selenium используется для тестов с эмуляцией пользователя.
    А методика юнит-тестирование как правило описана в документации к используемым инструментам.
    Ответ написан
    1 комментарий
  • С помощью чего писать тесты для сайта?

    @xfg
    Из популярных для юнит-тестов
    mocha
    jasmine
    Для end-to-end тестов
    nightwatch
    protractor

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

    Функциональные (end-to-end) тесты эмулируют поведение пользователя через реальный браузер. То есть end-to-end тест нажимает кнопочки, заполняет поля, ходит по ссылкам. Эти тесты более медленные, чем юнит-тесты. Изменения в верстке страницы могут их поломать. Но они более высокоуровневые, дают убедиться, что страница работает именно так как предполагалось. Не зависят от кода, а следовательно не имеют проблем с DOM в отличие от юнит-тестов.

    Лично я пишу только юнит-тесты. И не пишу интеграционные и функциональные. Юнит-тесты очень быстрые, можно в автоматическом режиме прогонять при каждом сохранении файла проекта. В тоже время они дают приемлемый уровень уверенности в том, что билд проекта скорее будет работать, чем нет. Если писать все типы тестов, то можно выстрелить себе в ногу. Будет медленее. Будет больше проблем с исправлением кучи всяких разных тестов.
    Ответ написан
    1 комментарий
  • Что означает ошибка 40: Too many levels of symbolic links?

    ArtyomovAnton
    @ArtyomovAnton
    PHP и всё что рядом
    Что то мне подсказывает, что у вас nginx.
    И возможно ISPmanager.
    Уберите в конфиге хоста nginx: disable_symlinks if_not_owner
    Ответ написан
    Комментировать
  • Как уйти с распутья технологий?

    @VZVZ
    Reverse-Engineer, Software Developer, Architect
    С таким подходом я далеко не уеду и я это понимаю.

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

    А я реально пробовал. И нашел себя именно как универсал, "всего понемногу", но зато до глубины.
    И я тоже занимаю свою нишу.
    Есть задачи, где лучше узкий спец, чем я.
    А есть задачи, где лучше я, чем узкий спец.
    А есть задачи, где просто я. И точка.
    Ответ написан
    1 комментарий
  • Как уйти с распутья технологий?

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

    Прочитали книгу по Java - попробуйте запилить простенькое приложение под Android. Прочитали про C# - начинайте ваять сайт на ASP.NET или приложение WPF. Авось в процессе экспериментов к чему-нибудь душа да ляжет.
    Сейчас, по-моему, наоборот: сплошь и рядом люди просмотрят 2-3 видео урока и сразу начинают что-то делать, не вдаваясь в теорию (что сказывается на качестве кода). А вы вот в другую крайность впадаете.
    Ответ написан
    Комментировать
  • Как уйти с распутья технологий?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    @lakegull
    Да бизнесом однозначно заниматься! Вы просто задали этот вопрос на форуме, где >80% аудитории простые исполнители, вот они и советуют вам становиться "хорошим программистом".
    Становитесь руководителем и нанимайте хороших исполнителей, зарабатывайте деньги.
    Ваша задача развивать в себе навыки предпринимателя: искать спрос и создавать продукт руками тех, кого вы нанимаете. Ваши навыки в программировании помогут вам грамотно делегировать задачи, но вы не должны париться по поводу, что со временем разучитесь кодить. Вместо этих навыков появятся более важные.
    Ответ написан
    2 комментария
  • В кого переквалифицироваться из программиста?

    @Neonoviiwolf
    Flutter developer
    Не нравятся делать чужие, попробуйте свои
    Ответ написан
    1 комментарий
  • В кого переквалифицироваться из программиста?

    Alexey_Suprun
    @Alexey_Suprun
    Web Developer Blog - ссылка в описании
    Начинайте вести бизнес, открывайте собственную студию!
    Ответ написан
    3 комментария
  • Почему web-сервисы стали называть API или какая между ними разница?

    Denormalization
    @Denormalization
    Многие заказчики под API понимают совсем даже не API.
    Я понял эту фишку, и всегда пишу заказчикам "Делаю классное API под ваши требования". Херня? Работает!

    Забейте на всех. API - это стильно, модно, молодежно. Все делают API, и я буду делать API.
    Если заказчику нужно API для формы обратной связи, которое будет посылать ему СМС - я ему сделаю такое API.
    Термины для старперов.
    Ответ написан
    2 комментария