Трудовик в Хогвартсе
  • «Дия Сити» — цифровой колхоз

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

    Поддержал: Artem Lyba
  • Тени незабытых айтишников. Или сколько потеряет государство, если айтишники уйдут в тень?

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

    Поддержали: kraken, Andrew Frolov
  • Quality in embedded solutions

    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 CI-driven verification or more loose, you might use Jenkins, TC or even dedicated build-boy for these activities, but all this still will be a CI.

    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.

  • Quality in embedded solutions

    Sorry for possible inconvenience, it should be written as “following CI-defined procedures” :)

    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.

  • Quality in embedded solutions

    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.

  • Quality in embedded solutions

    Not only staff. It also creates a certain overhead of time, that should be used by developers for tasks, related to CI-following procedures.

  • Quality in embedded solutions

    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-based approach, means, that “fixing and polishing” activities have higher priority, than creation of new functionality.

  • Quality in embedded solutions

    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”.

    Поддержал: Viktor Zhurbenko
  • Quality in embedded solutions

    So this guys will move your project in directions opposite to quality:
    Could you explain, why, especially for CI?
  • Мінсоцполітики врегулювало ситуацію на ринку «аутсорсингу» найманої праці

    Это может быть не связано с налогами. Например, я нанимаю специалиста, который «нужен везде, но ненадолго, месяцев на пару» (наладчик оборудования, например) и перепродаю его услуги тем, кому они нужны.

    Смущает в статье только то, что «государство что-то недополучает».

  • shitware

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

    Кроме того, банк как раз редко заводит у себя «совершенно новый продукт», обычно это царство вечного саппорта и допиливания по периферии.

  • shitware

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

  • shitware

    Поэтому за «интересные» проекты никто не будет платить денег.
    Не полностью согласен. Платить будут — крупным корпорациям нужен не только саппорт, но и R&D. И этот самый R&D вполне себе идет. Но в багфиксе/саппорте действительно зачастую платят больше.
  • Работать на заграничный аутсорс или местный перспективный проект?

    Емкость внутреннего рынка очень мала, в основном это работа на госсектор.

    + работа с разными финучреждениями и их автоматизацией различных процессов.

  • Заговор детектед!

    Со скриптами
    Костыль на костыле для реализации чего угодно, что не является формочками интерфейса к БД.
    Толстый, ресурсоемкий и не совсем кроссплатформенный клиент с закрытым кодом и отсутствием внятных сторонних реализаций. Практически — еще одна операционка.
    А он-то тут при чем?
  • shitware

    Вся прелесть и ирония ситуации в том, что зачастую под «продуктовой» компанией подразумевается одно из двух:
    — стартап

    — компания, некогда сделавшая ОДИН продукт (как правило, специфический и/или не слишком многоаспектный) и с тех пор живущая на саппорте и багфиксе.

    Корпорации добра с десятками направлений деятельности, походу, не рассматриваются, как место для работы в принципе :)

    Поддержали: SemiCoder, Beaver Green
  • Заговор детектед!

    Это как раз две стороны одной медали. Веб-интерфейсы — это как раз самая надводная, самая спорная и, пожалуй, самая бесполезная часть перемещения этих приложений в сеть. Основной идеей и бенефитом массового SaaS является перемещение в сеть именно «вычислительной части». Это дает возможность:

    1. Непрозрачно для пользователя обновлять софт: меньше геморроя с поддержкой разрозненного зоопарка версий и конфигураций, единая точка обновления
    2. Находиться в едином правовом поле: не нужно учитывать патентное и антимонопольное законодательство разных стран
    3. Более надежно защититься от реверс-инжиниринга собственных алгоритмов как в техническом плане, так и в законодательном (грубо говоря, за несанкционированное проникновение сажают/штрафуют в больших странах, нежели за дизассемблирование)

    4. Гибче управлять лицензиями, особенно триальными и ограниченными по времени.

    Построить же Rich-интерфейс в браузере пока что плохо выходит даже на ПК, не говоря о мобильных ОС. На то есть много причин — начиная от того, что веб изначально не задумывался, как средство реализации подобных интерфейсов и приходится городить костыли в виде джавы/флэша для его имитации и заканчивая тем, что в мобильных платформах никто в здравом уме не даст запускаемому в браузере приложению доступ «наружу» браузерного сандбокса иначе, чем через некие организованные самой ОС каналы.

    Поддержал: Олексій Пєніє
  • Янукович ветировал законы о поддержке ІТ

    еще один теоретег, предлагающий отправить в крематорий 10 млн пенсионеров?

    Кстати, забавно: во всех подобных дискуссиях регулярно видны предложения что-то сделать с пенсионной системой и практически не встречаются предложения что-то сделать с выплатами за детей :)

  • Янукович ветировал законы о поддержке ІТ

    Удешевить деньги. Кредит под 25% в год — смешно.

    Увы, без серьезной стояны раковой для банковской системы именно этот пункт попросту нереален. Во-первых, наша валюта склонна к инфляции и «10% в гривне» по сути, значит «бесплатно». Во-вторых, большинство наших банков не выдают в качестве кредитов депозитные деньги, а перепродают деньги, взятые в кредит на более выгодных условиях на мировом рынке. Без маржи такие операции не будут иметь смысла.

  • Янукович ветировал законы о поддержке ІТ

    Икобо — это не Белиз, это Антигуа и Барбуда :)

← Сtrl 1234567 Ctrl →