• Что является основной причиной говнокода?

    dom1n1k
    @dom1n1k
    Тут как посмотреть. Непосредственных причин, которые приводят к говнокоду, может быть очень много:
    1. Отсутствие внятной аналитики и архитектуры
    2. Низкая квалификация исполнителей (он может и хотел бы сделать хорошо, но не знает и не умеет)
    3. Говнокодеры по складу характера (есть такие люди, которым даже если создать все условия, все равно сделают на от****сь, потому что и так сойдет)
    4. Недопонимание и сложные отношения в команде
    5. Сроки (бывают заведомо нереалистичные, а бывают просранные в процессе)
    6. Меняющиеся требования
    7. Плохо выстроенные процессы (документация, тесты и пр)
    8. Текучка кадров
    9. Политика руководства
    И тд и тп... Можно придумать ещё много пунктов.

    Но в конечном итоге все эти причины можно свести к одной первопричине - плохой менеджмент. Хороший менеджмент это такой непонятный зверь... Трудно сформулировать, понять, организовать. Косяки не сразу видны и ощутимы, но потом выливаются в проблемы. Если у вас есть хороший менеджер проекта - он на вес золота.
    Ответ написан
    1 комментарий
  • Хорошая ли практика создавать свои классы Exception для отлавливания разных ошибок?

    php10
    @php10
    Разработчик на PHP
    Во фреймворках так и делают. Я в своей практике использую несколько исключений. Так что это нормально. Почитайте еще про интерфейс \Throwable, который появился в PHP 7
    Ответ написан
    Комментировать
  • Имеет ли смысл создание корневого класса с описанием магических свойств в PHP?

    BoShurik
    @BoShurik
    Symfony developer
    Если в проекте используются магические методы, то, имхо, что-то не так с архитектурой
    Ну и по поводу наследования: оно вам скорее всего не нужно https://en.wikipedia.org/wiki/Composition_over_inh...

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

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Структурно любой многопоточный парсер прост:
    У вас есть 2 очереди: задачи на скачку и задачи на собственно парсинг.
    Соответственно есть два вида воркеров.

    Первый вид воркера берет задачи из очереди на скачку, качает их каким-нибудь курлом и помещают в очередь на обработку.

    Второй вид воркера - каким-то образом разбирает контент и пихает его уже в итоговое хранилище.
    Разбирать лучше всего регулярками - это работает быстрее всего.
    Ответ написан
    2 комментария
  • PHP ORM для бизнес приложений?

    artemylapko
    @artemylapko
    Symfony, Doctrine developer. Немного js и python.
    Doctrine. Возможно в начале будет не очень легко, нужно только выбросить из головы всякие active record и т.д. Но когда вникнешь в суть, уйти от доктрины не сможешь.
    Ответ написан
    6 комментариев
  • Где найти WordPress right way?

    OtshelnikFm
    @OtshelnikFm Куратор тега WordPress
    Обо мне расскажет yawncato.com
    Где найти WordPress right way?
    https://www.wptherightway.org/en/
    Ответ написан
    Комментировать
  • Как преодолеть кризис начинающего специалиста?

    @0x131315
    Да, программист - не так романтично на деле, как кажется)
    Потому что, в отличии от всяких мечтаний, в реале вопрос завязан на деньги, а деньги - на время.
    Программист работает на заказчика, заказчику нужно быстро и дешево - отсюда готовые решения и костыли сейчас, с прицелом разобрать это потом (но потом тоже костыли)
    Поначалу все это очень напрягает и срывает башню - нас учили не такому, нас учили стремиться к простому и оптимальному коду, а везде вокруг накручивают дичайшие костыли, и это жесть, но...
    Со временем понимаешь, что лучше сейчас быстро сделать костыль, и забыть об этом, возможно навсегда, чем потратить времени в 3-4 раза больше, но сделать по канонам... Просто у программиста нет столько времени...
    В конце концов в реальности работа программиста не так сложна, и во многом не так красива, как ожидается - по большей части это рутина и разгребание чужого страшного кода, отладка и ваяние своего страшного кода, сожаление о том, что не было возможности сделать хорошо, и радость, когда попадается что-то интересное, или то, что сделал хорошо, качественно
    Как и на любой работе, есть свои светлые и темные стороны. И деньги не так легко достаются - программист за них щедро платит нервами. Как и врач, и любой другой специалист
    Ответ написан
    1 комментарий
  • Как (и возможно ли) дотянуться до Junior JavaScript Developer в кратчайшие сроки?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Во первых: совершенству нет предела.
    Во вторых: невозможно объять необъятное и впихнуть невпихуемое.
    В третьих: как ты не крутись, а технологии развиваются быстрее, поэтому отставание неминуемо, как следствие приходится всегда чем-то жертвовать ради чего-то более важного.

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

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

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

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

    Меня на программирование пропёрло весьма рано, лет в 14-15. Я ощущал собственное безграничное могущество, послушная железяка выполняла любое моё повеление, любой мой каприз, при условии, что он правильно сформулирован. Если железка не делала что нужно, или делала что не нужно, то это всегда была моя вина, это значило что я прокосячился. Подобное осознание настигло меня весьма скоропалительно, после чего мозг начал усиленно дисциплинироваться, и количество лютых фейлов пошло на убыль.

    Коммерческая разработка - это, примерно, от 70% времени/сил на дебаг и фиксы, потому что мало где процессы поставлены грамотно. По хорошему до сего дня (а мне под 40) я только одну команду видел, где процессы прям вообще очень хорошо поставлены и мне посчастливилось какое-то время с ними поработать. За эти несколько месяцев я подрос на целую голову. Самостоятельно достичь сходных результатов было бы весьма затруднительно.

    Сам я сменил стек совсем недавно, начал в конце 15 года, и процесс продолжается до сих пор. Сменил я по одной простой причине - во всех моих прежних проектах большая часть логики с бэка уехала на фронт, и прекраснейший jQuery перестал справляться чуть более чем полностью. Он, по прежнему, хорош, но задачи, которые приходится решать, требуют совершенно других подходов. Для себя я выбрал React, но в целом на рынке имеются альтернативы. По моим данным очень большим спросом пользуется Angular 2+.

    Когда говорят о фронтенд разработке, постоянно говорят о технологиях, стеке, но почти никто не упоминает, что не стеком единым... Существенная часть разработки - это, для начала, понять задачу и построить у себя в голове модель. Заказчики бывают разные, от очень толковых, до очень безтолковых. Соотношение первых ко вторым примерно 1% и всё остальное... Т.е. в большинстве случаев тебе скажут минимум, своеобразно, плюс ты это поймёшь по своему. Потом, по ходу пьесы, в самые неподходящие моменты, начнут всплывать подробности, которые: забыли упомянуть; ну это же очевидно, ты же профи; мы сами не знали, это только выяснилось; ну это же мелочи, мы думаем тебе это будет не сложно; а ты не спрашивал; и т.п....

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

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

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

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

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

    Даже если тебе попадается практически идеальный проект, внезапно оказывается, что твоя оперативная память это 5-7+-2 объекта, а удерживать в голове одновременно нужно сотни...

    Зачем я все это рассказываю? Затем, что это реальность, которая для джунов не делает исключений.

    Термин "фигак-фигак и в продакшен" встречается повсеместно, т.к. ресурсы (деньги, время, кадры) практически всегда весьма жестко ограничены и ничего ты с этим не поделаешь.

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

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

    Теперь относительно того что делать - если в бэкграунде нет сильных скиллов по алгоритмике и структурам данных (олимпиады по программированию, универский курс информатики), то прям очень сильно рекомендую прокачать. Будучи наставником на нескольких курсах фронтенда я постоянно встречают студентов, которые "вроде бы" знают язык, но затрудняются скомпоновать пару циклов с условиями, вот буквально просто виснут на неопределенное время, причем без результата. Лично я рекомендую кодварс. Своих студентов я прокачиваю именно там. Достаточно прорешать 30-40 задачек, чтобы базовые скиллы ушли на уровень рефлексов и перестали парить мозг. Правда желательно решать это все с наставником.

    Косвенный бонус тут будет в том, что ты привыкнешь решать задачи на JavaScript. Я когда менял стек, поначалу мыслил на PHP, и подобный финт на кодварс позволил мне переформатировать мышление на JS. Вот мой профиль на кодварс как пруф: https://www.codewars.com/users/iCoderXXI

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

    Понять надо настолько глубоко, чтобы легко и просто, с юморком, рассказывать это любой первой встречной бабушке, да так, чтобы та всё поняла... Это вот прям залог успеха в JS, потому что все остальное держится на этих двух китах. В ютубе имеется курс Зоракса (Zorax) и JavaScript Weird Parts, оба про то же самое, первый на русском, второй на инглише. Кантор, безусловно, крут, но эти двое объясняют попроще и понятнее (имхо).

    После этого прокачиваемся в использовании встроенных методов JS, таких как map, reduce, includes, replace и пр. (на том же кодварс)

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

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

    Потом уже заостряемся на API форм, DOM, AJAX (fetch/axios), вебсокетах, Localstorage и пр.

    И вот только теперь можно переключаться на фреймворки. Проще всего освоить Vue (по слухам), наибольшим спросом пользуются React и Angular, для общего развития так же неплохо бы немного послушать про Ember.JS.

    React только на первый взгляд выглядит простым, на самом деле это только view-библиотека, а в любом нормальном SPA есть много чего еще кроме view, поэтому React всегда идет в компании Redux, Router, и еще целой толпы всего, что тоже придется осваивать, не только с точки зрения API, но и с точки зрения философии (а нахрена оно вообще сдалось?)

    Перед походами на собесы очень желательно иметь портфолио из нескольких готовых проектов, вылизанных стилистически.

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

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

    Еще вроде большие компании вроде Яндекса устраивают летнее обучение, с последующим трудоустройством лучших кандидатов, но это не точно.

    Оптимистичный прогноз - 6-12 месяцев плотного фигачинга и ты в тренде.
    Ответ написан
    7 комментариев
  • Обращаюсь к тем кто в СПб и у кого есть Thinkpad t520?

    ntkt
    @ntkt
    Потомственный рыцарь клавиатуры и паяльника
    Клавиатуры *20 и *30 последних поколений совместимы :
    Как минимум, на примере x220 и x230:
    forum.thinkpads.com/viewtopic.php?f=69&t=104889

    Но будут проблемы из-за BIOS: не будут работать многие из клавиш.
    Его надо специально патчить (что никто, похоже еще не сделал).

    Но тенденция все более удручает — судя по всему, Thinkpad как бренд достойных устройств для дела умер окончательно и бесповоротно в момент продажи в lenovo.
    Ответ написан
    Комментировать
  • Best practicies валидации Entity properties в Symfony 2

    slimus
    @slimus
    Symfony, Golang
    Вам нужно начать с этого мануала: symfony.com/doc/current/book/validation.html
    Коментарий выше описал еще один варианнт валидации. Тут все на любителя: мне не понравились аннотации и я все конфиги пишу в yml, в том числе и валидатор.
    Пока более конкретного на Ваш вопрос ответить нельзя потому что вопроса то и нет. В мануале написаны все случаи которые Вам могут пригодится на первом этапе, если будут вопросы — задавайте в этой ветке, постараюсь ответить
    Ответ написан
    3 комментария
  • Что изучать веб-программисту самоучке, кроме самого языка?

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

    Что касается веба (но применима к любому языку, да и не только)
    Изучили php — посмотрите как оптимизировать. Как закэшировать и тд
    Изучили MySQL — изучите оптимизацию запросов.
    Изучили JS — найдите как более рационально его применить.
    Оптимизируйте сервера, в общем все что только можно.

    Извиняюсь за излишнюю эмоциональность. Просто наболело и надоело видеть кучу тормозного кода.
    Начиная от сайтов заканчивая приложениями.
    Ответ написан
    1 комментарий
  • Что такое вселенная?

    Mrrl
    @Mrrl
    Заводчик кардиганов
    Вселенная — четырехмерный (как минимум) объект, обладающий метрикой пространства-времени.
    Большой взрыв — самая ранняя по времени точка Вселенной. «До него» ничего и нигде существовать не могло, потому более ранних точек пространства-времени не существует.
    Вероятно, Вселенная бесконечна и «плоская», т.е. её геометрия евклидова — с хорошей точностью. Она более-менее однородно заполнена материей (в масштабах метагалактик, т.е. сотен мегапарсеков), и её масса бесконечна.
    Вложено ли пространство-время Вселенной в какое-нибудь пространство большей размерности — неизвестно. Есть теория «мембран», которая предполагает, что да. Но лучше считать, что нет(с).
    Говорить о «пространстве вокруг Вселенной» нельзя — она заполняет всё пространство. Расширение идёт не за счет движения — просто увеличивается расстояние между точками (обычно приводят пример надувающегося воздушного шарика, но надо учесть, что кроме поверхности этого шарика ничего нет — а все точки этой поверхности неподвижны). Так что вопрос «в какую сторону расширяется» смысла тоже не имеет. Просто расширяется.
    Другие перемещения есть. Например, местная группа галактик движется относительно реликтового излучения со скоростью 300 (или 600?) км/сек. Существует ли «более инертная» система отсчета, чем реликтовое излучение — пока неизвестно.
    В своём пространстве-времени Вселенная одна, и столкнуться ей не с кем. Другие Вселенные с нашей информационно не связаны. «Белых дыр», которые могли бы служить «выходами» порталов между Вселенными, пока не обнаружено, а что находится по ту сторону чёрных дыр — тоже неизвестно. Известно только, что оно в бесконечно далеком (по нашим часам) будущем.
    В теории мембран Вселенные столкнуться могут. Возможно, в результате таких столкновений и происходят события, видимые как «большой взрыв». Но это надо изучать подробнее.
    Ответ написан
    2 комментария
  • ICQ-клиент, не страдающий ожирением и рекламой

    @edogs
    miranda, в базовой версии она портейбл и даже смайликов там нет.
    Для удобства придется унавозить парой плагинов (без проблем качаются на офф.сайте) под себя, но это не проблема опять же.
    Ответ написан
    Комментировать
  • Программирование. С чего начать ребенку?

    ntkt
    @ntkt
    Потомственный рыцарь клавиатуры и паяльника
    10 лет это, вроде, уже в 5-й класс пора?
    !!! СРОЧНО !!! в достойный маткружок, натаскиваете как раз к сентябрю, когда обычно идут вступительные испытания. Мозги вправляет только так. Программирование потянется само, скорее всего расскажут/заинтересуют прямо там.

    Если достойного кружка в радиусе дневного перехода нет (или не возьмут, или еще что), то берем материалы, например, здесь: zaba.ru/ и учим сами.

    Даю такой совет, опираясь на выборку людей, прошедших через маткружок 239 и/либо СПбГДТЮ на рубеже миллениума.
    Ответ написан
    1 комментарий
  • Программирование. С чего начать ребенку?

    noldo32
    @noldo32
    С ассемблера и отладчика!
    Ответ написан
    Комментировать
  • Проблема с клонированием Git репозитария

    nicolnx
    @nicolnx
    Буквально на днях столкнулись с аналогичной проблемой на github. Саппорт ответил:

    I've just found the problem. Some external program has created two references in a non-standard reference path for your repository:

    9bebfe5719bba5dc39b27f9fdfb872b4f56c1029 refs/for/refs/heads/dev
    c165d9c5adea628a67c1ede7aca6232aee53e86c refs/for/refs/heads/master

    The `refs/for/refs` path is non-standard and confuses old Git clients. AFAIK, these references are created by Gerrit. I've manually removed those two references, and clones should work again, but if you continue using Gerrit, the problem will persist. The only workaround is updating your version of Git to the bleeding edge.

    Обновили клиенты до 1.7.10 и проблема ушла.
    Ответ написан
    1 комментарий
  • Кто шуршит моим винтом? Расскажи-ка мне о том!

    pel
    @pel
    Еще посоветую Anvir Task Manager

    Кроме очень широких возможностей таск менеджера, может показывать детально (с именами процессов) нагрузку процессора, памяти, использование винта и сети.
    Ответ написан
    2 комментария
  • Кто какую книгу считает своим "стартом" в мир IT?

    super
    @super
    А.Ларченко, Н.Родионов — ZX Spectrum для пользователей и программистов. Считаю что это лучшая книга по IT тематике которую я когда-либо читал. По ней изучал Assembler.

    image
    Ответ написан
    2 комментария
  • Интерактивная синхронизация папки с сервером?

    molann
    @molann
    Посмотри SyncBack (есть Freeware-версия) — я в свое время использовал ее для синхронизации полезного софта на компе и флэшке (когда приходилось бегать с актуальным набором софта на флэшке), сейчас через нее периодически синхронизирую критическую инфу на внешний винт.
    Кол-во настроек синхронизации имхо более, чем достаточное и одновременно достаточно понятно организовано.
    Ответ написан
    2 комментария