• В чем моя причина провала тестового задания Яндекса?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ну давайте я покритикую:

    возьмем файлик

    1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

    class Travelsort {
        constructor() {}
        sortTickets(tickets) {}
    }


    2) вы не умеете пользоваться исключениями.
    if (!Array.isArray(cards)) {
        throw new ValueError('Wrong input');
    }


    3) использование let там где должен использоваться const

    4) в принципе использование переменных там где их быть не должно

    5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

    6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

    7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

    8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

    Далее... берем следующий файлик

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

    2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

    Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

    3) очень много дублирования.

    4) очень плохо с protected variations.

    Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.
    Ответ написан
    17 комментариев
  • Как быть в курсе, что происходит у себя на сервере?

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

    mourr
    @mourr
    Passionate JS developer
    Взгляните например на Peer.js - WebRTC+Socket.io библиотека, есть видео звонки из коробки. Можно адаптировать под что угодно, есть куча готовых примеров (втч с видеозвонками)
    Ответ написан
    Комментировать
  • Где можно найти реальные тестовые данные на 10М+ записей?

    savostin
    @savostin
    Еще один программист
    Ответ написан
    Комментировать
  • Где можно найти реальные тестовые данные на 10М+ записей?

    bavaria
    @bavaria
    Студент, Python, Ruby
    • 1.6M reviews and 500K tips by 366K users for 61K businesses
    • 481K business attributes, e.g., hours, parking availability, ambience.
    • Social network of 366K users for a total of 2.9M social edges.
    • Aggregated check-ins over time for each of the 61K businesses
    Yelp dataset
    Ответ написан
    Комментировать
  • Как происходит разработка веб приложений у профи?

    sim3x
    @sim3x
    Один коллега посоветовал мне сначала писать тесты, а потом уже под них писать код. Мы так еще не делали, хотим внедрить. Действительно ли это эффективно?

    Да, так пишется меньше кода :)

    Только в последовательность выглядит так
    0. Пишем тест под новый функционал
    1. Стартуем тесты = прогон тестов должен занимать до 2 сек
    2. Видим новый проваленный тест
    3. Фиксим его

    Но в любом случае, сначала заводится тикет в багтрекере, потом вешается на себя, потом делается "гит пулл", а уже после того добавляется код

    Различные среды дев/прод/тест должны готовится автоматом + должны быть в виде готовых образов для виртуалок или для докера.
    Последовательность: пишется скрипт для сборки образа, отправляется в репозиторий, ночью или моментально машина, ответственная за образы, собирает его и разраб может ею пользоваться.
    ИМО дев/прод/тест не должны различаться на данном етапе - все модификации окружения должен проводить софт, который ассоциирован с ЯП/средой, в которой ты занимаешься разработкой. Допустим ты работаеш с нодой и тебе нужны пакеты для оптимизации цсс - npm install а на продакшене такое не нужно и ты делаешь npm install --production

    Но все ети заморочки не добавляют скорости разработки - они не дают разводить на проекте бардак и, теоретически, повышают качество кода
    Ответ написан
    Комментировать
  • API для работы с Viber. Есть опыт?

    @aradon
    PHP-Developer
    У Viber нет открытого API. Только закрытое, получить к нему доступ могут только очень крупные компании. Первыми в СНГ насколько мне известно это сделали LiqPay. Сейчас так же соглашение подписала одна крупная украинская компания, занимающаяся смс-трафиком. Но условия этого соглашения строго запрещают отправлять что-либо кроме технических, сервисных сообщений, типа паролей, уведомлений и т.п. Никакой рекламы.

    API может быть только со стороны каких-то компаний, которые написали свой софт для рассылки по Viber и реализовали API к этому софту.
    Ответ написан
    Комментировать
  • Выбор средств для разработки высоконагруженного веб приложения?

    viktorvsk
    @viktorvsk
    системы (веб сервис), которая должна выдерживать высокие нагрузки и быть масштабируемой.

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

    Насколько такой вариант будет выдерживать высокие нагрузки?

    насколько будет быстро работать, учитывая динамическую типизацию


    Это называется преждевременной оптимизацией

    Вам не могут ставить требования "сделать производительную и масштабируемую систему". Вам могут сказать соотношение чтения\записи в базу, ожидаемый RPS (стабильный и пиковый), максимальное время ответа на запрос...

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

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

    Если у вас есть опыт с джавой в вебе - делайте на джаве.

    Есть опыт с джаваскриптом - делайте на основе веб-сервисов.

    У каждого подхода есть плюсы и минусы и обычно они субъективны.

    Лучше потратить 2 месяца на прототип и потом - месяц на переписывание, чем сначала 3 месяца думать и делать - а потом понять, что нужно было двигаться в другую сторону.

    Описаны ~80% случаев и ваш с вероятностью > 90% попадает именно в эту область.
    Ответ написан
    1 комментарий
  • Где взять первых клиентов?

    un1t
    @un1t
    Можно написать другим студиям, у многих есть работа которую они аутсорсят или готовы просто отдать лид, порой даже без условий, потому что либо не совсем профильное либо, в данный момент нет своих ресурсов.
    Скажем студия пишет на Yii, Django и express.js, а часто клиенты обращаются с Symfony, Битриксом и Drupal.
    Или ценовая категория не та. Кто-то не делает коробочные дешевые сайты, а кто-то наоборот не делает дорогие индивидуальные решения, но ко всем периодически обращаются и с тем и с другим. Кто-то не занимается поддержкой чужих проектов. Кто-то не держит своих верстальщиков, а аутсорсит верстку.
    Ответ написан
    Комментировать
  • Адаптивная вёрстка - как побороть боль?

    @c030f5da
    Не хочу быть КЭПом, но все проблемы в вёрстке начинаются с дизайна. Адаптивная вёрстка может быть только у адаптивного дизайна, иначе это уже три макета, а не адаптивность. При хорошем подходе к дизайну, верстать по сути приходится только мобильную версию - остальные разворачиваются из оной чутьли не автоматически.
    Ответ написан
    7 комментариев
  • Из верстальщика во фронт-ендера, какие технологии изучать в дальнейшем?

    Ronnie_Gardocki
    @Ronnie_Gardocki
    Я у мамы фронтендщик.
    0) Ванилла js это и есть обычный js.
    1) Начинать надо с одновременного изучения ваниллы и jQuery. По ванилле будете читать книги и всякие статьи, типа как работают замыкания, this, hoisting и так далее. А на jQuery вы собственно будете писать код, который будет что-то, да делать. Никто вам конечно не мешает забить на jQuery и по хардкору угарать только по ванильному жсу, но с огромной вероятностью, вместо того чтобы как то реально практиковаться в написании кода и выполнении каких-то простых задач, вы будете биться головой о стену, ибо для начинающего, работа с DOM (а только и этим можно заниматься поначалу) в ванилле это настоящая пытка. Очень важно пилить много велосипедов.
    2) Параллельно прокачиваете css. Там просто поле непаханных возможностей и фишек. Со временем скорее всего придет понимание того, что чего то в обычном css не хватает. Тогда и начнете юзать препроцессоры. Можно конечно и сейчас сразу начать, но я не уверен что от этого будет хоть какая-та польза (а вот риск начать юзать вложенность в full-retard mode имеется).
    3) Как только начнете писать хоть какой-то вменяемый js или юзать css с препроцессорами, тогда и придет пора автоматизации фронтэнда. Галпы, автопрефиксеры, склеивание/миницирование стилей/js и все такое. Об этом пункте вообще можно будет не париться долгое время, ибо все ваши задачи будут решаться установкой какого-нибудь генератора yeomana с маджонгом и гейшами.
    4) Фрейморвки. Ангулары, реакты, эмберы и так далее. Будете их изучать на основе статей и пет-проджектов, ибо на нормальную работу, где эти самые фрейморвки применяют, с 90% вероятностью не возьмут без опыта владения ими. Учить их все естественно не надо. Достаточно хорошенько покопаться в 1-2, чтобы понять принципы работы основных частей.
    4 пункт может с легкостью идти сразу за вторым, если вас больше интересует копание в жсе, и не особо интересно представление. Параллельно со всем перечисленным изучите стайлгайды, методолгии, модульные системы и все подобные вещи, которые необходимы для написания приличного кода.
    Ответ написан
    Комментировать
  • Как с помощью CSS сделать угол на блоке?

    teotlu
    @teotlu
    Навёрстываю упущенное
    Сгенерите себе вот здесь стрелочку из прямоугольника, с помощью наклона, поворота и изменения ширины, чтоб получился нужный угол. А дальше сможете к ней применить box-shadow, как к обычному элементу. Но его значения, конечно, придётся подбирать). Поддерживаться будет в IE9+.
    Ответ написан
    Комментировать
  • Как научиться писать технические задания для разработчиков?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    Все программисты ненавидят вот такой бред, где мелким текстом описываются задания и изредка прилагаются невнятные скриншоты.

    Освойте мокапы, чтобы рисовать схемы элементов, освойте специальные программы для создания скриншотов (вроде той что встроена в яндекс.диск и позволяет рисовать поверх картинок всякие стрелочки и комменты)

    Вот это уже будет понятное всем ТЗ, а не бумагомарание.

    Пара программ для создания мокапов вам помощь:
    ninjamock.com
    https://balsamiq.com/products/mockups/
    Ответ написан
    3 комментария
  • Нужно ли включать маршрутизатор в изоморфную часть?

    MarcusAurelius
    @MarcusAurelius Куратор тега Node.js
    автор Impress Application Server для Node.js
    С дублированием сложно смириться морально. Но есть три пути, два Вы описали, дублировать и изоморфить. Но мне больше по душе третий, когда серверная часть содержит все в себе, обобщенную решаемую задачу и динамически порождает клиентскую часть. То есть, нужно не 2 раза писать, а используя метапрограммирование подняться на такой слой абстракции, где нет клиента и сервера и там решать задачу, а потом транслировать ее в клиент и сервер, в шаблоны и маршруты в конкретику.
    Ответ написан
    1 комментарий
  • Как организовать команду по разработке сайтов и правильно делегировать задачи?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    1. Искать адекватных фрилансеров с похожим стилем мышления и взглядами - так больше шансов что сработаетесь. Объединяться не только по работе за деньги, но и придумать себе дополнительное сотрудничество, например, какой-нибудь совместный Open Source проект, или коммерческий продукт - и тем и другим может быть плагин/тема для WordPress или что-то подобное. Например, тема в двух вариантах - бесплатная Lite для WordPress.org и промо себя любимых, платная Pro для ThemeForest. Такая дополнительная работа позволит всегда быть в одной лодке и теснее работать на общее благо, это отразится и на коммерческих проектах. Кроме того, это всегда бонус и для клиента - например, в заказах по WordPress клиент видит, что я и мои ребята висим на WordPress.org как разработчики плагинов/тем, один у нас вообще в ядро WP контрибьютит. Это большой плюс в карму.

    2. Не увеличивать команду без надобности. 1 человек фронтенд, 2й - бекенд. Дизайнер на первых порах лучше проектно. Расти строго по мере острой необходимости, хотя новых людей надо искать заранее и тестировать в реальной работе. То есть, должно быть постоянное "ядро" команды, и еще несколько на подхвате. Поначалу они на подхвате (и работают себе самостоятельно в остальное время), со временем кто-то из них переместится в ядро, по мере роста.

    3. Со студиями/агентствами надо работать в обратном направлении. У многих из них часто бывают завалы и нехватка собственного ресурса, вы должны быть подрядчиками у них, а не наоборот.

    4. Бюджеты. Самое главное :) Кто-то умный когда-то сказал:
    The kind of clients we attract is directly related to our rates

    Что означает, что качество клиентов прямо зависит от ваших цен. И второе, из опыта - геморроя плюс-минус одинаково в проекте с бюджетом 200$, и в проекте с бюджетом $2000. Времени и усилий на поиск/привлечение клиента тратится столько же. И чаще всего те, кто платит $2000 больше ценят время, работу, и не имеют мозг без острой на то необходимости (см. цитату выше).

    5. Снижать стоимость привлечения клиента (под стоимостью подразумевается и время, и деньги). Повторные / постоянные клиенты - наше все. Оставлять клиентов на поддержке, делать так чтобы они обращались повторно с доработками / развитием своих проектов, приходили с новыми заказами, советовали другим. Например, я вчера закончил интересный проект для повторного клиента. Первым заказом были небольшие фиксы платного шаблона, 2 часа работы / $60, через биржу. Спустя некоторое время он обратился уже за целым сайтом для бизнеса своего отца. Адекватный бюджет. Сделали, запустили вчера. У него уже опять готов список новых фич для этого сайта, через месяц где-то вернется с ними и снова загрузит работой. Имея хотя бы с десяток таких клиентов, можно заполнить половину рабочего времени, не тратя время на поиски новых клиентов. И гемора с ними нет, и с оплатами никаких проблем, и т.д.

    6. Для того, чтобы п.5 в реальности происходил, недостаточно просто делать работу вовремя и хорошо. Нужно клиенту помогать, обучать его, советовать. Недавно был случай - клиент пришел со стандартной задачей пофиксить платный шаблон под его требования. Поковырявшись в этом ужасе и задав кучу правильных вопросов стало понятно, что этот шаблон ему вообще не подходит для этих задач. Проект был переориентирован в разработку с нуля, из $120 бюджет сменился на совсем другие цифры. Задача ведь не просто кнопки понажимать и что-то там накодить, а помочь клиенту решить его задачи. Ему результат в целом важен, а не количество строк кода, которые вы написали, или насколько правильно этот код отформатирован.

    7. Снижать себестоимость разработки. Накапливать типовые решения, код, который можно (и нужно) использовать повторно. В случае с готовыми CMS (а это самый распространенный формат работы) - покупать девелоперские неограниченные лицензии на те плагины, которые существенно экономят время. Мы, например, купив однажды ACF Pro для WordPress существенно уменьшили себе объем работы на каждом проекте. Сейчас будем брать Gravity Forms или Ninja Forms для того, чтобы решить вопрос с формами и кастомными фронтендами, которые жрут кучу времени и сил в разработке даже со своими наработками. Плюс какие-то мелкие решения, которые часто нужны.

    8. Написать для себя стратегию развития. Четко понимать, куда хотим прийти и в какие сроки (плюс-минус), четко определить, что делать, что двигает в этом направлении, а что нет. Тогда будет шанс из кучки фрилансеров вырасти в студию или что-то в этом роде. Без стратегического видения фриланс - это белка в колесе и замкнутый круг. Вечная погоня за небольшими деньгами "на пожрать и отложить на отпуск". Стратегия может быть разной, например, "вырасти в студию", "создать свои коммерческие проекты / онлайн-сервисы", "стать богом в одной конкретной сфере и собирать сливки со всех фриланс бирж - получать самые жирные проекты в этой нише" и т.д.
    Ответ написан
    1 комментарий
  • PHP, унаследовать объект в процессе исполнения, можно ли?

    65536
    @65536
    часть путей вычисляется в классе А

    пути должны вычисляться в ваших файлах автолоада

    https://php.net/manual/ru/function.spl-autoload-re...
    Ответ написан
    Комментировать
  • Cуществует ли легковесная реализация Data Mapper + UnitOfWork + Repository?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    М.... не знаю такой.

    Есть https://github.com/doctrine/skeleton-mapper

    Еще есть Spot2 но оно без UoW, надо будет докручивать самостоятельно (благо реализации есть).

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

    Igor-Maf
    @Igor-Maf
    Senior Front End developer
    1. Настраиваю gulp на основные таски (конкатенация, минимизация, удаление неиспользуемого, кросс-браузерность, sass и т.д.)
    2. Подключаю через bower необходимые "модули", например, normalize.css или фрэймворк
    3. Выстраиваю архитектуру кода (просто независимые блоки в отдельную директорию, например, "modules", или "pages" для стилей особенностей отдельных страниц), в корне css главный файл стилей, в котором осуществляется импорт всех модулей (например, файл с переменными цветовой палитры или файл с mixin-ами).
    4. Подключаю необходимые шрифты, в основном, через специальный миксин.
    5. В главном файле стилей описываю основные стили для типографики, в общем всё, что связано с селекторами типа.
    6. Если дизайнер предоставляет styleguide, то начинаю верстать страницу именно с него, а именно, по независимым блокам (где это возможно, от меньшего к большему) используя БЭМ методологию.
    7. По ходу дописываю задачи для менеджера задач, например, для скриптов или картинок, собираю необходимый package.json, bower.json.
    8. Собственно этап по-блочной верстки.
    9. Собираю конструктор из готовых блоков и элементов соответственно макету.
    10. Проверяю кроссбраузерность, pixel perfect.
    11. Этап исправления деталей

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