Java Developer
  • 1С забули? Є хто на заміну?

    вирішує проблеми бізнеса, а не уявлення «інженерів» про ті потреби

    З таким підходом часто приходять до автоматизації хаосу, що не є ефективним. Але ж «бізнес знає краще». «Люди з бізнесу» з важливим виглядом приходять і кажуть «хочем порахувати все» і «звіт мені на пошту». Їм кажуть «ваші процеси — гавно, тре все переробити», а вони «ви що діти? не треба нічого міняти — все оцифрувати як є». Так і живем ... і маєм «кровавий enterprise». Нажаль такі дискусії рідко закінчуються тверезим аналізом.

    Ну і, насправді, підприємець, який виробляє глечики і веде облік купленої глини в зошиті, звісно ж, «краще знає» як оцифровувати процеси, ніж інженер, який вже бачив купу таких систем.

    бо так — дешевше для малого і середньго бізнесу.

    Дешевше тоді, коли воно не потрібно. Тоді ще дешевше буде взагалі не вести непотрібний облік.

    Підтримав: K Vadym
  • 1С забули? Є хто на заміну?

    треба просто знати чому ентерпрайз — кривавий.

    Кровавий він із за того, що бізнес «не ідеальний», ні замовники, ні процеси... до того ж все міняється щодня + зробити треба за 3 копійки.

    бухгалтер просто робить запити до БД на SQL.

    Як на мене баланс «десь посередині» ... але зараз це може бути трохи довга дискусія.

    не намагатись зробити ERP систему.
    то кому вона буде потрібна?

    Це питання і є показує головну проблему (на мою думку). Умовно, облік можна поділити на податковий (мета: вірно порахувати податки та подати вірні звіти), фінансовий (мета: абстрактно показати «як справи» в компанії) та операційний (мета: наприклад, знати звідки і коли приїхала ота пляшка кефіру на полиці, її ціну, скільки на ній заробили, тощо).

    Так ось, ці три види обліку, в певному сенсі, мають різні правила і вимоги. В результаті, все ліпиться в купу і виходить ... 1с ))

    Невеликій ТОВці потрібно тільки мінімум для контролюючих органів, наприклад. І по зарплаті потрібні лише сума та податки, а не купа різних схем нарахування та трекінгу відпусток.
    Не впевнений, що тут навіть подвійний запис проводок потрібен.

    Фінінсовий облік потрібен там, де власники хочуть тримати під контролем цифри. Хоча реально його аналізують одиниці. Та й в нас він часто ведеться більше «для галочки» і взагалі не дає ніякого розуміння ситуації.

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

    Операційний облік — то взагалі окремий світ і тут як раз отой ERP та «кровавий enterprice» має місце. Більшості він зовсім не потрібен, комусь треба мінімум для інтернет магазину, комусь повний трекінг товарів/матеріалів/складів, а комусь і купу внутрішніх процесів.

    Коли я казав про «unix way», я мав на увазі те, щоб як раз не мішати це все в одну систему.

    Підтримали: ipsumicin, K Vadym
  • 1С забули? Є хто на заміну?

    Не впевнений, що розумію всю складність процесу, але з того що я бачив, 1С — це до неможливості переускладнена система (конфігурація для України).

    Складається враження, що програма робилась по «тому як сказав бухгалтер» і толком аналіз задачі не проводився і «хочу тут галочку» — це ставилась як вимога.

    Бухоблік — по суті — це БД з планом рахунків, проводками, що генеряться по правилах з купки реєстрів, і звіти по цих проводках. І це все. Достатньо зробити гарну платформу для цього. Для решти є сенс зробити зручний спосіб інтеграції/апі. Склади/магазини/акції/зарплати — то окремі системи, виходом з яких буде якийсь простий реєстр документів.

    План рахунків в нас в країні ± стандартизований. Звіти по ним в податкову по цьому стандарту, мали б могти формуватись.

    Реєстри документів, можна зробити штук 10 стандартних і цього 96% підприємств мало б вистачити.

    Головне, як на мене
    — не намагатись зробити ERP систему.
    — зробити просту систему, яка робить одну задачу — бухоблік, але робить її круто (unix way?)

    В цілому, те що я написав чимось схоже на 1с, але без зайвого, простіше, відкритіше та модульніше.

    Ідея для стартапу )) Але якось не хочеться влазити в це на років 10 ))

  • ex-Google та євангеліст Flutter розносить вщент аргументи хейтерів фреймворку

    но ведь тайпскрипт как-то решает проблему js’а, зачем сюда dart?

    Простіше зробити було з нуля і нормально. TypeScript тягне за собою все погане з JS (погане для цього застосування).

    Я програмую на flutter, і безмежно щасливий, що там не js.

  • ex-Google та євангеліст Flutter розносить вщент аргументи хейтерів фреймворку

    Dart складно порівнювати з будь-якою з наведених мов.

    Мені здається, що цю мову обрали не із-за того, що просто захотіли, а із-за того, що вона ідеально підходила для задачі.

    З того, що я знаю про kotlin та js, то ці мови б багатьма своїми фічами заважали. Вони не для цього створені були.

    Щодо решти (с++, rust) — так то зовсім інша історія. Ці мови зовсім не для цього.

  • Мовний скандал в Andersen: співзасновник компанії офіційно вибачився і прокоментував інцидент

    Вибачте, не погоджуся )) Про територію екс-союзу можна вести дискусію, звісно. Але ІТ — це сфера, де робочою мовою була і є англійська. І якщо вже спілкуватися не рідною, то є сенс англійською (інакше всім треба буде знати три мови, замість двох)

    Та й вся ця дискусія про інтернаціоналізм... зазвичай згадується в контексті «давайте будь-якою мовою, якщо вона російська», що є ще однією спробою нав’язати свою мову куди дотягнуться руки.

    Підтримали: Roman Pavlyuk, Iurii Bazai, JP
  • Велика кількість бібліотек, сувора динамічна типізація та проста логіка. Розробники — про переваги та недоліки Python

    У вашому випадку хоч stub ± нормальний, хоч і без доків.

    Я більше про щось типу mongodb-шного
    find_one(filter=None, *args, **kwargs)
    І в доках «any additional keyword arguments are the same as the arguments to find()».
    Що хоч і не зручно, але фіг з ним ... можна глянути що там у find.

    Але якщо глягути
    mysql.connector.connect(*args, **kwargs):
    То тут ... хз ... тільки йти в гугл з «mysql.connector examples».

    **kwargs іноді використовується по ділу, а іноді ... «а давайте два параметри обробимо тут, а решту передамо далі». Ланцюжок з 3-4х таких викликів і 10-15хв треба вичитувати як там що передати... в кращому випадку.

  • Велика кількість бібліотек, сувора динамічна типізація та проста логіка. Розробники — про переваги та недоліки Python

    Багато сказано ... але забули про один, як на мене, критичний недолік: мова НЕ ide-friendly. Анотації типів допомагають, ала слабо.

    Коли я роблю import xxx, перше, що я роблю — це пишу «xxx.» і дивлюсь що там. І так, в python, з цим все ок. Але з купою методів з **kwargs — не видно нічого ... і єдиний варіант — шукати документацію, що є дуже довго для 90% випадків.

    Підтримали: Anton Melnyk, Roman Mogylatov
  • В FAANG после 36

    Якщо одразу тут побачити динамічне програмування, то задача досить проста.

    Але навик це бачити треба тренувати.

  • Співбесіда з DevOps. 300+ запитань для Junior, Middle, Senior

    Як і часто буває, багато питаннь biased на те з чим працюють ті, хто питають. На самій співбесіді це є норм, адже людину під це і шукають, а ось в такому списку не дуже.

    Ansible, як на мене, несправедливо обділили увагою )

    Ну і з голови написати consumer для черги — таке собі ... якщо протягом останнього місяця це не робив, то перший запит в гуглі буде на доку по клієнту для потрібної черги.

    А в цілому, цікаво ... є що погуглити )

  • Один із розробників MySQL покидає проєкт. Він його розкритикував і радить користуватися PostgreSQL

    Колись теж mysql був один на сервері ... але зараз відійшли від цього.

    Зараз стараємось так не робити. Одна база на сервер — це велика база і це проблема: це мінімум пару терабайт бази, їх важко бекапити, важко запустити репліку(великий снапшот), важко розгорнути бекап, важко апгрейдити (якщо downtime, то один і великий і страждає все)

    До того ж репліка і відновлення бекапа по нормальному мали б використовувати точно ту ж версію mysql як і мастер. А керувати версіями в умовах mysql з пакетів — то щось неймовірне.

    Тому зараз ми стараємось різати по можливості десь до 200-400Gb баз на instance. На кожен instance виділяється окремий lvm, на бекапі снапшотиться і в фоні архівується (практично, без downtime ... лиш writelock на пару секунд для снапшота). Це все в докері з фіксованою версією: апгрейд — окрема процедура, якщо дуже багато з’єднаннь, то DNAT замість docker proxy. Відновлення з бекапа — практично ідеальне: розпакувати, переслати і run.

    Все працює як треба ... єдиний мінус — це те, що навантажена база з активним lvm снапшотом помітно просідає. Коли це важливо, снапшот робиться з репліки.

    Можливо, у вашому випадку, реалії інакші, але після того як ми налаштуавали все згадане (+ prometheus), питаннь до баз в нас принципових не залишилось.

    Підтримав: Nikita Podgorbunskyi
  • Якою мовою ви читаєте? І на скільки це принципове питання?

    По трохи приходжу до думки, що російський контент — це в основній своїй масі є низькосортний rewrite. І на все, що може бути цікавим є значно кращий контент англійською.

    Короч, російський контент не хочеться читати не лише із за того, що росія є державою-гопником, а й із-за того, що толком унікального і корисного там знайти дуже важко.

  • Ще один підхід до локалізації Flutter-додатків, якого вам бракувало

    Особисто я не люблю кодгени

    Важко без них у flutter: moor, i18n, json_serializable ... хоча останній і допомагає, але не дуже ))

  • Ще один підхід до локалізації Flutter-додатків, якого вам бракувало

    Ми використовуємо щось дуже схоже ... тільки бібліотека i18n. Якщо я не помиляюсь, підхід як дві краплі води )

    Підтримав: Anna Leushchenko
  • Как Product-менеджеру избежать tunnel vision

    А які аргументи були щодо школи в 6 чи 7 років?

    В 7 років щоб легше було надавати однокласникам?

    В 6 років щоб вчитись, поки мозок ще «пластичний»?

  • Математика і розробка: які знання допоможуть програмувати краще

    Добре, що вашу модесь світу поділяють лише обмежена кількість людей ... інакше ми б досі жили б в печерах і відправляли б поштових голубів.

  • ❗️ Декілька додаткових слів про кібербезпеку

    Про Дія.Підпис — згоден з вами. Хоч там є ще PIN, але якось я не переконаний в захищеності приватного ключа.

    Щодо Id-карти ... не користувався — не знаю.

    Щодо даних ФОП і монобанк — це щось дуже дивне ... ні одна ні інша підтримка мені не сказали навіщо ці дані запитуються/передаються. Але тут скоріше вразливість server2server. Авторизація в додатку не мала б давати доступ до цих «clientId».

    Ну і тут авторизація через bankId — дуже зручно, але, по суті, зникає контроль за авторизацією, і яка кінець-кінцем прив’язана до номеру телефона, що є дуууже погано.

    В цьому всьому є лиш один «позитивний момент». Хоч я і прихильник КЕП в файликах, але люди часто не дуже безпечно їх зберігають та паролі від них (аж у файлі, що лежить поряд). І тут, хоч і суто математично захист слабший, але він кращий, ніж безвідповідальне поводження з ключами.
    На жаль, при цьому страждають і люди, що адекватно зберігають паролі.

    Про вибори ... не знаю як вони збираються це робити, адже як забезпечити прозорість, анонімність та непідкупність для мене не очевидно (без використання «довіреного сервера»). Це хоч взагалі математично можливо?

  • ❗️ Декілька додаткових слів про кібербезпеку

    Відстоюючи свою позицію потрібно старатись бути об’єктивним і, як мінімум, слідкувати за своїми аргументами. В цьому інтерв’ю експерт моментами перегинає палицю.

    Те, що впорядкування баз даних є тривалим процесом не означає, що не можна почати з чогось простішого. Влесне, у Дії зробили те, що змогли і з тим що було: показали не всі паспорти, не всі права, а лише ті, що могли. Це НЕ є погано.

    Самі паспортні дані не є чимось сакральним. Паспорт — це «сертифікат», що по своїй суті є публічним... в ньому немає нічого секретного. І навіть якщо вся б база паспортів населення планети стала б публічною — це нічого б не зламало. Відповідно, заходи безпеки у дії, звісно, необхідні... але agile — тут норм.

    Кредит по паспорту — це проблема не Дії, а тих хто його видає... адже при видачі варто було б звірити хоча б фотку з обличчя та отримати підпис звичайний чи КЕП.

    Сам факт того, що отримали доступ до Дії на чуже ім’я — то дуже поганий прецедент — тут питаннь немає. Але це не означає, що Дію треба закривати. Сам факт того, що за півтора роки роботи цей прецедент одиничний — це вже добре. З такими прецедентами треба, просто, адекватно працювати.(що, схоже, не було зроблено — саме на цьому є сенс акцентувати увагу)

    В контексті Дії є купа державних послуг (та ж реєстрація ФОП), але тут все спирається на існуючу інфраструктуру КЕП. Додаткових ризиків, яких би не існувало раніше, я не бачу.

    Відповідно, питання можуть бути щодо ДіяПідпис. В інтерв’ю про це не було дискусії, ... єдине, що можу тут сказати, що я особисто вважаю, що наша система з ЄЦП/КЕП — має серйозні вади. А саме те, що ключі не є спеціалізовані (чому ключем, який використовується для звітності по ФОПу, можна «взяти кредит»?). Як на мене, в саму інфраструктуру варто було б додати можливість для кожного ключа видати сертифікат для іншого ключа з підмножиною повноваженнь ... таку собі довіреність. ... але це окрема дискусія.

    Щодо bug bounty і решту... єдине, що хотів би сказати це те, що публікація вихідного коду державних систем — це те, до чого ми маєм прийти. Це складно, це відповідальність, але це рівень ... до якого нам ще далеко (((

  • Как создать безопасную авторизацию пользователей с помощью UUID

    1. HMAK => HMAC

    2. Для токенів немає сенсу притримуватись стандарту UDID. UrlSafeBase64(sha256(secure random)) — це ок.

    3. Питання корисності refresh token-ів не розкрито: stackoverflow.com/...​access-and-refresh-tokens

    4. Так, ви перевинайшли серверні сесії. Але ви розібрали в цьому механізмі краще, ніж 90% тих, хто роками цю стратегію використовуює ... і це круто.

    5. Питання statefull та stateless хоч і розкрито, але неявно. JWT придумали щоб серверу не потрібен був redis для сесій ... коли користувачів мільярди, а серверів тисячі, тримати один редіс для токенів — то є проблема (хоча, шардування ще ніхто не скасовував)

    Підтримав: Petro Sasnyk
  • Математика і розробка: які знання допоможуть програмувати краще

    Доведення вивчають з двохи причин:
    1. Ключові доведення показують нові способи «якими можна думати»
    2. Для того, щоб математика не перетворилась в релігію, а підручник — в біблію. Якщо ви не вірите в будь-яку теорему, завжди можна почитати її доведення і або знайти помилку, або переконатися у вірності.

    ПС. Відчуваю себе людиною, що ведеться на хитрого троля. Ви дійсно вірите в тези, що пишите, чи це вкиди для розігріву дискусії?

    Підтримали: Michael Budash, Богдан
← Сtrl 123456...24 Ctrl →