Ответы пользователя по тегу Веб-разработка
  • Владение какой технологией/ЯП в США имеет наибольший шанс на получение хорошей работы?

    @uelkfr
    Я думаю так:
    1) JavaScript - высокая востребованность и зарплата
    2) Java - высокая зарплата, средняя востребованность
    3) C/C++ - высокая зарплата, не подходит для молодежи, низкая востребованность
    4) перспективно Scala, Closure, Rust
    5) в США наверное Objective C и Swift популярны

    По технологиям:
    1) Web Backend (centos, ubuntu, debian, Docker, Docker Swarm/Kubernetes, ansible, systemd, supervisor, nginx, haproxy, php5-fpm, nodejs, postgresql, mysql/mariadb/perconaserver, redis, cassandra, Consul, Ceph, ElasticSearch/Sphinx)
    2) Web Frontend (html6, web 3.0, css5, es8, nodejs, gulp, grunt, browserify, angularjs, react, flux/redux, mocha, selenium-webdriver, protractor)
    3) Android/iOS (менее перспективно BlackBerry, Sailfish OS, Ubuntu Touch)
    4) Databases (ext4, Ceph, Oracle, PostgreSQL, Cassandra, ElasticSearch/Sphinx)
    5) Big Data
    Ответ написан
  • Почему использование триггера в mysql/oracle/mssql ... в web-программирование (и не только) считается признаком говнокода?

    @uelkfr
    Они мешают локализации бизнес-логики внутри вашего приложения. Т.е. бизнес-логика разделяется на две части и на два языка программирования. Рассмотрим каждый из недостатков по отдельности.

    1. Бизнес логика разделяется на две части. Этот недостаток особенно проявляется при использовании веб-фреймворков и в частности паттерна ORM. В паттерне ORM при создании, обновлении, удалении объекта через шину событий вызываются обработчики события, в них и пишется бизнес логика, а хранимые процедуры этого лишают. Хранимые процедуры дают оптимизацию и у программистов есть недостаток к преждевременной оптимизации, что может привезти к резкому усложнению архитектуры и кода.

    2. Бизнес-логика пишется на двух языках программирования. Во-первых нужно знать, хорошо знать, два языка. Во-вторых, нужно вводить Coding Style Standarts еще для одного языка. В-третьих, языки хранимых процедур (T-SQL, PLSQL и т.п.) не очень подходят для написания сложной бизнес-логики, а современные требования к бизнес-логике как раз требуют софистики. Вообщем код получается запутанным, нечитаемым, сложно модифицируемым и т.д.

    Я признаю только триггеры, только util-триггеры. Например, триггер запрещающий удаление записей в определенной таблице, это можно сделать с помощью прав, но лучше дополнительно защитить триггером который будет распространятся глобально на всех пользователей. Второй пример, это триггер подсчета количества записей в таблице, как известно COUNT(*) на больших таблицах обходит весь индекс по PRIMARY KEY, а вообще большие таблицы зло - лучше сразу шардить.

    P.S. На опыте скажу сталкивался с системой КИС УЗ Модус, разработчик отказался разрабатывать сервер и запил всю бизнес логику на T-SQL и вызывал их из клиентского десктопного приложения. Вообщем печальная была система.
    Ответ написан