Есть одна большая, я бы сказал, стратегическая проблема. Это все хорошо, пока деньги нужны на сугубо «текущие» нужды. Квест начинается в случае капитальных приобретений — квартиры, дома, машины, я уже не говорю про кредиты — тут вопрос «черных» доходов вызывает ощутимые проблемы, особенно, если параллельно будут поджимать финмониторинг и светить все подобные транзакции в наших банках. Особенно если таки введут нулевое декларирование и вариант «это я за все время до этого накопил» работать перестанет.
There are no sense to talk about common CI not because CI fails there but because CI will change so much than you will be definitely misunderstood.Look, CI might change very much, depending on project needs, you might establish more tight procedures over
The OPPOSITE approach to CI is approach, when we’re free to commit and build anything, you could skip static analyzer checks, you could neglect failing unit tests and actually ignore anything outside of scope of your project — until you will reach some defined point (and this point is rare, like once in several months), where INTEGRATION starts — and there you’re ought to fix everything to make it compliant to defined rules.
Sorry for possible inconvenience, it should be written as “following
General source of this overhead is like following: you wrote some code and you want to commit it (not just to “save”, but also to share to other team members, who need it. But before it will be available, you should make it pass all the checks: code review should be done, tests should be written and passed, checks by static and dynamic analyzers should be performed (f.e. in private builds) and so on. It make a huge number of benefits for quality, but disabling “rapid changes”, if some change to code base should be provided immediately.
Yurii, I have used CI in embedded for a few years. And in the most of projects it was no more than just “something on jenkins” or in better situation “a try to be sure than nothing was broken yesterday”.So, does having experience only with poor CI processes implementation, allows to say, that overall CI is something not necessary?
I have not so much expirience with embedded projects, just something ~3 years. And I’ve seen quite complex — and working well — CI schemes, that really worked for improving quality (at least, when looking for number of issues, found in products during all procedures, requested by CI steps). The biggest issue with it was one, I’ve mentioned before — CI drastically increase non-development people’s time allocation in project. From one side, it’s quite a boring activity for skilled developer, all this polishing of small warnings from static analysis and writing unit tests for each piece of code, from other side, if project is not fixed-bid, customer might want more people “just writing code”, and it’s not easy to show ROI over CI/process-managing activities in a short term. Moreover, quality (and outcome) of established procedures was really varying, based on whether project team had cared over “health” of these procedures.
Not only staff. It also creates a certain overhead of time, that should be used by developers for tasks, related to
If you move your CI enough close to Quality corner your CI will change so much than nobody will recognize your CI as CI.
CI is very simple concept, and it could be recognized in any corner of this triangle. Generally, CI is just a set of practices, that looks very simple — you do different checks over your code as often, as possible — like “at least per commit”. And CI NEVER make quality worse — it might make huge impact on time (==price, feature delivery time, number of people, who’s doing something other, but writing a production code), because you should fix everything, before you can commit: some unit tests failed — fix this, static analysis shows possible uncertain behavior — fix this, etc. With established CI procedures, you’ll never skip required steps — and here’s the possible problem #1 — you’re unable to make “rapid changes”, like “upload something to make other team member work with this, while you’re still polishing” but rapid changes!=quality.
From my past experience, usual problems with CI over embedded projects are not related to decreasing quality, but with following stuff:
— Hard to create auto-deployable builds for tests in CI. There might be a bunch of reasons for this: device is a kind of commercial secret and we can’t connect it to our network, testing of our changes require to build and deploy the whole firmware (like a few hours task of doing nothing), we don’t have enough devices to use them for something, not related with actual development etc.
— CI practices require to have people, who should maintain overall infra for this. And, depending on how complex your build process is and tests of which complexity do you want to have, such people might cost not less, that True Norwegian Senior Developer. And it’s not always easy to explain to customer, why should he pay for a person, who doesn’t write code.
— CI practices decreasing development velocity, especially, when several people are working in a tight-connected sessions of code. And moreover, having
CI (and any other practices) could be focused on any goals from triangle you’ve mentioned. And you are speaking about automated tests, static analysis, valgrinding etc — all this stuff is usually part of CI procedures (at least, they could be set up as steps for creation of stable and revertable build). And having quality focus with this is very easy — the only disadvantage of this approach is that devteam will be high-loaded over non-production code writing activities (like “we should correct all Prevent warnings, and we should cover this with autotests, and then we’re getting more warnings from massif/valgrind, we hate this, we want to write something interesting, not this bsht” — this is a common scenario for quality-focused CI processes).
CI, despite word “integration” is not only about integrating any new features, it’s something about “code you’ve committed, is OK”, and it’s usage is crucial, when you can’t afford project structure, like “one person write one big and completely independent feature across the overall project duration”.
So this guys will move your project in directions opposite to quality:Could you explain, why, especially for CI?
Это может быть не связано с налогами. Например, я нанимаю специалиста, который «нужен везде, но ненадолго, месяцев на пару» (наладчик оборудования, например) и перепродаю его услуги тем, кому они нужны.
Смущает в статье только то, что «государство что-то недополучает».
Речь не о культе, а о процессе. В банке жизнедеятельность программиста вписана в совсем не IT-шный процесс, причем фазы этого процесса зачастую не трассируются на разработчиков, за счет чего авралы возникают ощутимо чаще.
Кроме того, банк как раз редко заводит у себя «совершенно новый продукт», обычно это царство вечного саппорта и допиливания по периферии.
Разница принципиальнейшая. В продуктовой компании разработчик — это сама основа существования оной, не будет разработчиков — не будет продукта, менеджеры-маркетологи там вторичны. В банке IT-отдел — обслуживающий персонал, прямой прибыли не приносящий.
Поэтому за «интересные» проекты никто не будет платить денег.Не полностью согласен. Платить будут — крупным корпорациям нужен не только саппорт, но и R&D. И этот самый R&D вполне себе идет. Но в багфиксе/саппорте действительно зачастую платят больше.
Емкость внутреннего рынка очень мала, в основном это работа на госсектор.
+ работа с разными финучреждениями и их автоматизацией различных процессов.
Со скриптамиКостыль на костыле для реализации чего угодно, что не является формочками интерфейса к БД.
флэшемТолстый, ресурсоемкий и не совсем кроссплатформенный клиент с закрытым кодом и отсутствием внятных сторонних реализаций. Практически — еще одна операционка.
хтмл5А он-то тут при чем?
— компания, некогда сделавшая ОДИН продукт (как правило, специфический и/или не слишком многоаспектный) и с тех пор живущая на саппорте и багфиксе.
Корпорации добра с десятками направлений деятельности, походу, не рассматриваются, как место для работы в принципе :)
Это как раз две стороны одной медали. Веб-интерфейсы — это как раз самая надводная, самая спорная и, пожалуй, самая бесполезная часть перемещения этих приложений в сеть. Основной идеей и бенефитом массового SaaS является перемещение в сеть именно «вычислительной части». Это дает возможность:
1. Непрозрачно для пользователя обновлять софт: меньше геморроя с поддержкой разрозненного зоопарка версий и конфигураций, единая точка обновления4. Гибче управлять лицензиями, особенно триальными и ограниченными по времени.
Построить же Rich-интерфейс в браузере пока что плохо выходит даже на ПК, не говоря о мобильных ОС. На то есть много причин — начиная от того, что веб изначально не задумывался, как средство реализации подобных интерфейсов и приходится городить костыли в виде джавы/флэша для его имитации и заканчивая тем, что в мобильных платформах никто в здравом уме не даст запускаемому в браузере приложению доступ «наружу» браузерного сандбокса иначе, чем через некие организованные самой ОС каналы.
еще один теоретег, предлагающий отправить в крематорий 10 млн пенсионеров?
Кстати, забавно: во всех подобных дискуссиях регулярно видны предложения что-то сделать с пенсионной системой и практически не встречаются предложения что-то сделать с выплатами за детей :)
Удешевить деньги. Кредит под 25% в год — смешно.
Увы, без серьезной стояны раковой для банковской системы именно этот пункт попросту нереален. Во-первых, наша валюта склонна к инфляции и «10% в гривне» по сути, значит «бесплатно». Во-вторых, большинство наших банков не выдают в качестве кредитов депозитные деньги, а перепродают деньги, взятые в кредит на более выгодных условиях на мировом рынке. Без маржи такие операции не будут иметь смысла.
Икобо — это не Белиз, это Антигуа и Барбуда :)
При наличии своего жилья, вроде как. В случае аренды (особенно традиционной для наших условий «вчерную») — все сильно сложнее, нужно либо искать фейковый адрес для регистрации, либо пытаться договариваться с хозяином, что сильно не всегда удается.