Как стать автором
Обновить
16
0
Vitali Havryliuk @via-site

Web Architect

Отправить сообщение
«Учитесь на практике. Не надо покупать/читать книги. Не надо записываться на курсы. Не надо платить учителям. Просто гуглите и пользуйтесь тем, что уже освоили.»

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

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

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

В английском языке нравится определение «strong problem solvers», в русском языке аналог для этого наверное «решалы». По моему мнению, именно это и есть правильное определение настоящего программиста.

P.S. Программированию нельзя обучить, ему можно только обучиться.
Firebase позиционирует себя как BaaS (Backend as a Service), т.к. он предоставляет хоть какую-то настройку прав доступа + регистрацию/авторизацию/аутентификацию. Если клиент — это простой CRUD или что-то типа того, то мне кажется этого должно хватить.

CouchDB, Couchbase,… позиционируют себя как DBaaS (DataBase as a Service) и как мне известно все же требуют хоть какого-то сервера, на котором и будут определяться права доступа к базе.

Сначала хочу попробовать подружить PouchDB и Firebase. Сейчас не особо хочется заморачиваться с серверами. Но на перспективу все же смотрю в сторону независимой от сторонних сервисов архитектуры.
Последние несколько месяцев разрабатываю «Offline First Progressive Web App» (для работы с очень плохим или вообще без Интернета). С самого начала планировал использовать Firebase для быстрого старта.

Проблема возникла уже в самом начале, т.к. браузерный клиент Firebase не поддерживает полноценную офлайн работу. Лучшим решением что я смог найти оказался как бы порт CouchDB в браузеры — PouchDB и во всех современных (и не очень) браузерах он работает просто великолепно. Из коробки есть встроенная, автоматическая синхронизация с CouchDB (пока не проверял) или DBaaS сервисами типа: https://console.ng.bluemix.net/catalog/services/cloudant-nosql-db

Вот сейчас сижу и думаю: «зачем мне вообще использовать Firebase, если PouchDB — Simple Server — CouchDB / DBaaS CouchDB решают все мои проблемы?»
Считаю абсолютно правильным и логичным решением автора статьи соскочить с умирающего Angular 1.x на технологию, которая в ближайшие годы (а может и дольше) будет держать лидирующие позиции на рынке.

Сам предпринял аналогичный шаг практически в то же время (чуть раньше). Эта история мне до боли знакома.

Вначале я и сам столкнулся с небольшим отторжением Angular-CLI (webpack), т.к. у меня уже была собственная система сборки на Gulp + SystemJS и было просто жалко выбрасывать свои наработки + сборка работала в разы быстрее и понятнее (на тот момент).
Трезво оценив перспективы использования коробочного решения от самих разработчиков Angular + заметив интеграцию с Angular-CLI в моей любимой IDE, принял решение использовать как бы стандарт для работы с Angular приложениями и считаю что не прогадал.

Сам фреймворк довольно стабилен и проблем вообще не возникало, кроме роутера. Роутинг в приложении довольно сложен (lazy-loading, named outlets, multiple childs), но все мои задумки все же удалось реализовать, хотя и через… Думаю что в следующих релизах они доведут до ума и сам роутер. Но это все мелочи.

Единственная серьезная проблема, с которой я столкнулся — это катастрофическая нехватка готовых, стабильных веб компонентов на Angular 2, к которым я привык еще в первой версии. Понимаю что это временная проблема всех новых фреймворков, но все же хотелось бы использовать привычные инструменты уже сейчас. Хотя Angular Material 2 еще в альфе и довольно сырой, пришлось использовать именно его, т.к. Google's Material интерфейс просто шикарен, особенно на мобильных устройствах. Фреймворк для CSS разметки (Angular 2 Flex-Layout) — вообще в глубокой альфе, а Twitter Bootstrap и Angular Material не совместимы.

Еще очень порадовала уже работающая AOT компиляция (prerendered templates). Там проблемы с интеграцией в Angular-CLI, но все же она работает.

P.S. Я, как и большинство ангулярщиков, понимаем что Angular 2 — это совсем новый фреймворк, имеющий с Angular 1.x общего только первую часть названия. Вначале, весь многолетний опыт работы с Angular мне даже мешал и его пришлось пришлось просто выбросить. Наверное в этом есть удел всех хороших программистов-разработчиков. Мы быстро переучиваемся. Правда, среди знакомых есть еще и те, кто начинал еще с Backbone и до сих пор на нем работает. Мне их почему-то искренне жаль. Жаль еще бывших коллег, которые допиливают проект на AngularJS, осознавая что в данный момент получают опыт, который уже не актуален.
Очень хорошо понимаю автора статьи. Столкнулся с подобной ситуацией месяц назад, правда в более легкой форме (спасибо политике Хабра).

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

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

Еще, особенно радует когда кричат об отсутствии не заявленного функционала, типа:
— «Попробал. Ерунда какая-то. У вас не работает то, что именно мне нужно ...»

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

Но почему нельзя было просто написать:
— «Попробал. Вроде как полезный сервис. Но мне не хватило такого-то функционала»
— «Спасибо. Действительно полезный функционал. Непременно реализую»

Согласитесь. Ведь это реально приятнее и намного лучше повышает мотивацию.

Еще не понравился «троллинг» со стороны как бы «профессоров» / «академиков». Лично я их называю пустозвонами, которые сами в жизни ничего реального не сделали, но всех высмеивают и самоутверждаются за счет других. Особенно они любят собеседовать неопытных программистов и не любят или очень осторожно собеседуют опытных, ведь в этом случае могут опустить и их, при всех коллегах. Из личного опыта, мне кажется что такие есть практически во всех компаниях. Зачастую это менеджеры всех рангов. Но странно видеть таких среди представителей технических специальностей.
Большое спасибо за статью.

Лично для меня это было очень познавательно и смог вынести из нее много новой информации. Оказалось что мой собственный модуль локализации, который просто биндит значения в HTML из соответствующего языку JSON файла — это не более чем примитивная поделка на 10 строк кода.
Простите. Но сравнивать Генератор с тестером — это как сравнивать программиста с тестировщиком.

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

Надеюсь теперь, наконец, станет понятна та мысль, которую я хотел донести с самого начала.
Посмотрел. Довольно интересное они выбрали решение и в отличие от предыдущих комментариев — это действительно Генератор.
Мне кажется именно об этом и писал alexeyw в своем первом комментарии.
Простите. Но следуя вашей логике, все мы должны еще программировать на Ассемблере и писать код не в IDE, а в консоли.

Я серьезно.
Зачем нам высокоуровневые абстракции?
Зачем нам GUI, если есть консоль?
Зачем что-то вообще автоматизировать/улучшать/облегчать?
Зачем вообще прогресс?
Пока не спешу открывать исходники. Возможно позже, когда выйдет версия 2.0
Как и писал в статье, именно от таких сотрудников и пришел первоначальный запрос на подобный функционал.
По некоторым комментариям, уже понял свое упущение.

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

Чем больше будет примеров для того, что вы действительно хотите провалидировать — тем лучше будет результат (в теории).
Да. Эти варианты в примере скорее всего будут полезны. Добавлю, спасибо.

Знаю что есть еще вариант доменов на кириллице или других письменностях, но указывать их все в примере — это уже перебор.
https://uiregex.firebaseapp.com/ru — настоящий урл сервиса. Тоже «вечный» и бесплатный. А тот короткий — просто зеркало.

На гитхабе хостинг одностраничных приложений на порядок хуже чем в Firebase (нет html5Mode, настроек кэширования файлов, редиректов ...)
Про интерефейс полностью согласен. Надеюсь на большое число конструктивных отзывов.
IP — спасибо, пропустил.
Простой интерфейс — это была моя самая большая боль. Пробовал разные варианты, но на данный это максимум что я смог получить.

Если у кого есть предложения по упрощению, тогда только рад буду данной информации.

P.S. пожалуйста, только не предлагайте пределать в простой tester, т.к. цель именно не в ручном в создании регулярки.
Понял свою ошибку. Только холиваров не надо!
Нет. Эти регулярки работают со строками/текстом, которые приходят нам от пользователя. Не важно на клиенте это или на сервере. Наша задача — проверить что введенные данные действительно соответствуют нашим ожиданиям (регулярке).

Информация

В рейтинге
Не участвует
Откуда
Bern, Bern, Швейцария
Дата рождения
Зарегистрирован
Активность