lof*t. ha a marketing mukodik, a cegek megveszik, sikeres. hogy is volt a masik szalban a cpanel-lel? oh wait :)
en nem felek, hogy azt a 100 misit ne hajtanak be az ugyfeleken :) (amugy meg egy "jobb" uj auto ara, kvazi nevetseges tetel)
Oké, nem tudom, mekkora a cég kapitalizációja, de emlékeim szerint tizenhuszonakárhány éve a hazai KKV-knek nem sok olyan ügyviteli rendszer volt a piacon, ami naprakészen megfelelt az adóhivatal épp aktuális bürokráciájának.
A szoftveren kívül nem kapcsolódik a hírhez, csak beírom ide tanulságnak, más ne járjon így.
Kulcs-Soft VM-ben futott Windows 10 OS-en, ESXi-n, 5 éve. Az ESXi host elment nyugdíjba, az új szerveren Proxmox 8 van.
VM átmásol, driver rendbe tesz, minden szuperül működik, kivéve a Kulcs-Soft. 13-as hiba, nem sikerült a licenc érvényesítése. Ügyfélszolgálat: töröljük a szoftvert az új gépen, az eredeti gépről csináljunk mentést (a szoftverből), deaktiváljuk a licencet az eredeti gépen, telepítsük újra az új gépen, töltsük vissza a mentést, adjunk meg a licencet, működni fog. Nem így lett.
Telepítettünk egy vadi új VM-et Win10-el, arra a programot, betöltöttük a mentést, licencet adtunk neki: 13-as hiba.
Újabb vadi új VM, immár minden virtuális hardvert (amit csak lehet) ugyan az a Proxmox-on, mint ESXi-n volt (LSI SAS, VMXNET3 NIC, stb., nyilvámn így is csak hasonló, nem ugyan az), program telepít, adatbázis visszatölt, licenc odaad: 13-as hiba.
Ügyfélszolgálat: pedig annak mennie kellene. Egyébként Ők nem tudják mi a 13-as hiba oka. Mondom az üf-nak: nekik megvan a forráskód, csak tudják a saját programjukról, hogy milyen esetben ír ki 13-as hibát...
Munkatársam véletlenül elkottyantotta a kihangosított telefon mellett, hogy az egész egy VM-ben fut. Ügyfélszolgálat azonnali reakciója: ja! azt nem támogatjuk, nem tudunk segíteni a hiba megoldásában, tessék fizikai gépre tenni. De mondom 5 éve VM-ben futott. Nem tudunk segíteni, viszont hallásra.
Szégyen szemre kellett vinnünk egy mini PC-t a vadi új virtualizációs szerver mellé, amin ez a nyomorult program fut (már csak nem egy folyton ki-be kapcsolt munkaállomásra tesszük).
Nyilván valami hardver azonosítót figyel a licencelés miatt (ez azért mekkora gáz már 2024-ben!), és a Proxmox/qemu VM-ben nem azt olvasta ki, amit szeretett volna.
Még egy apró adalék: az eredeti gépen a programot elindítva azt írja: aktiválva. Felhívtuk az ügyfélszolgálatot, nem lehet az a gond, hogy a deaktiválás ellenére aktiválva van az eredrti helyen? Válasz: a deaktivált program újbóli elindítás esetén automatikusan aktiválja magát... Nesze neked kiszámíthatóság.
A CPU típust próbáltatok változtatni? Hány CPU magot/socketet adtatok a windowsnak?
Régen voltak ilyen phenom X3 nevű AMD-s csodaprocik aminél az SQL2k szerver telepítése folyamatosan elhasalt és csak egy hibakódot adott vissza. Nagy nehezen kiderítettem, hogy csinál egy ellenőrzést telepítéskor és mivel 2 hatványa a magszám(vagy valami hasonló) ezért nem megy át a teszten. BIOSban vagy Windowsban 1 mag letilt és viola megy a telepítés...
Elsőre az eredeti működő VM-et másoltuk át az új host-ra, amiben addig működött a program.
Egyébként mindig kettő hatványa számú magot adunk (nem is tudom hogyan alakult ez ki, 6, meg 12, meg ilyenek valamiért nem jutottak soha eszembe), ráadásul sima 1 socket felállásban ilyen egyszerű feladatra, szóval nincs NUMA meg ilyenek. Úgy emléxem 1 socket, 4 mag, 8 GB memória van konfigurálva.
De ha ennyi a másolt VM felélesztése, az még mindig nem magyarázza, hogy egy vadi új telepítés és érvényes licenc-el aktiválás miért nem sikerül.
Ráadásul egy ugyan így, de fizikai gépre frissen telepített rendszer meg simán működik mindenféle extra nélkül (probléma mentes aktiválás után).
Egyébként ki tudom próbálni, mert megvan az eredeti szerver, érintetlenül. Ahogy időm engedi, tesztelem!
konkrétan ezzel a szoftverrel nem teszteltem de a "system id" másolása az ennyi.
ezen kívül még a vm mac-jét is másolnám.
a kódot nyilván nem ismerem de simán lehet hogy van egy rész ami a már aktivált szoftver "érintetlenségét" ellenőrzi és van egy másik ami még az aktiválatlan szoftverhez húzza be az aktivációt.
Usecase: rendszergazda klónozza a wm-et,majd valamiért mindkettőben dolgoznak átmenetileg, vagy a klónozást követően még készül számla a régiben. Így azonos számlaszám mögött lehet különböző tartalom. A NAV nem fogadja be. Ügyfél visít. Na ez lenne a nagyobb gond, mert a new branch óta akár több ezer számla is elkészült.
Vegyük észre, hogy ez egy konyhavállalkozás volt, az újpalotai panelből indult (nem dzsentri volt). Szépen ment felfelé, sok cégnek példaértékű lehetne a növekedés. Az újgazdagok finomságait majd a következő generáció fogja vinni, a mostani sztárallűröknek hódol: Ferrari klub elnöke, golfklub elnöke és a biztonsági őr vitte a gyerekeket iskolába. Szerintem a tágadd ismerettségi körében sem volt még részvényes, pláne hogy ő bocsásson ki részvényeket. A tőke 90%-a az ő kezében van, látszat részvényeskedés. Ez a mostani játék pont nem jött be, 100m-t azért kidob magából és tanul belőle. Annyira biztos példaértékű mint a Musk és Bezos félék.
Ez az a Kulcsár, aki a yt-on ilyen short videókban oszt cégvezetési bölcsességeket? Kissé lábrázásom van tőle, hogy mindenféle szempontot felsorol a sikerhez, csak épp a termék minőségét nem :-(
Azt is vegyük észre, hogy a BÉT-en olyan könnyű manipulálni a kis részvények árfolyamait (záróár beállítás, stb), hogy én is tuti okoztam a bagatell vásárolgatásaimmal olyat véletlenül, ami nap végén a bet.hu főoldalára került (napi top min / max). Ettől még szemétség, de a kis piacon annyira triviális, hogy minimálbért megforgatva lehet itt olyan híreket generálni, hogy hajjajj :)
Ezt én is osztom, de hazai ügyviteli szoftverek között nem sok lehet (én nem tudok egyet sem), amit nem Windows-on, összekattintgatós fejlesztő rendszerben írtak, Windows-only kivitelben, sokszor MSSQL-only DB-vel.
Az is jó, mikor mondjuk (a Kulcs-Soft-hoz hasonlóan) Firebird a DB szerver, de a Linux-os üzemelést nem támogatja a SW gyártója. Vagy MSSQL, Express is jó, de ha Linux-ra tennénk 17-es vagy újabbat, akkor nem adnak supportot az egyébként Windows-only klienshez, mert biztos a Linux-on futó DB miatt van minden baja.
De ha van ilyen szoftver, szívesen veszem az infót, és a jövőben javaslom az ügyfeleknek, hogy legalább a saját életem könnyítsem.
P.s.: eszembe jutott, hogy egyet tudok, ami MySQL DB-vel működik (így Linux-on is mehet a DB), de az olyan szar, hogy ez sem segít rajta.
en el tudom kepzelni, hogy ez gazdasagi dontes. ha minden platform minden adatbazis kezelojet tamogatnak, a megnovekedett szakember igeny miatt a termek kevesbe lenne versenykepes.
Rettenetesen megnonek a koltsegek, ha a tamogatas nem annyit jelent, hogy "Jozsi egyszer mar majdnem sikeresen futtatta". Ha valos termektamogatast nyujt, beszallitoi/parneri szerzodesekkel rendelkezik marketinghez, ertekesiteshez, szallitashoz, deploymenthez, hibak felderitesehez (akar sima hibajegy irashoz - ugye nem gondoljuk, hogy ez ingyen van?), illetve rendszeresen teszteli a (helyes mukodes, karakterisztika, security stb.) a kiadasait a kulonbozo platformokon, kulonbozo 3P megoldasokkal, akkor siman tobbszoroset kolti el PLCM-re.
Ez egy kicsi, de legalabb nem gazdag piacon nem biztos, hogy a siker kulcsa.
Ez szepen hangzik a valosag ezzel szemben az, hogy excel makrokent indul. Majd Visual Basic-be torkollik, utana jon az MS Access, majd mar vesznek fel arcokat, mert kezd nagy lenni a ceg, es utana hatalmas code refaktoring utan kikotnek .NET + MSSql -nel.
Most hogy haladni kell a korral, esetleg Azureban futtatjak.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
A hazai gyártású ügyviteli szoftverek legalább 80% pontosan így jött létre, hogy valaki magának kezdte el csinálni, és mikor már elég sok munkát tettek bele, akkor döntöttek úgy hogy eladják másnak is, hogy visszajöjjön a befektetésből valami.
Ilyenkor persze kiderül, hogy egy random másik cég nem pont ugyan úgy működik, ahogy az eredeti fejlesztő cég, aztán így kiderül, hogy egy csomó dolog be van drótozva paraméterezés helyett, amit irtózat nehéz utólag átalakítani, a rendszer nem modulos, így nagyon nehéz különböző kiviteleket eladni a különböző igényekhez, stb. stb.
Tudok olyan szoftverről, aminél minden partnerhez saját support fejlesztő tartozott, aki a partner igényeit megvalósította, és ahány partner, annyi szoftver verzió élt egy időben, akár teljesen azonos verziószámmal, de tök különböző tartalom mellett... Meg voltak funkciók amiket többször fejlesztettek ki különböző partnerek igényeire, mert nem tudták, hogy az már másik partnernél megvalósult. Ez is egy olyan szoftverből nőtt ki, ami eredetileg saját felhasználásra készült.
A legszebb az ilyen sok ügyfélnek eladott motyóban az, amikor a DB-matató sql-ben ott figyel egy vagy több "...where foo.bar='masikügyfél'", vagy épp a binárisba bele vannak fordítva a használatra jogosult cégeknek az alapvető adatai - "természetesen" olvasható formában... Aztán ügyfélként csak vigyorogsz, hogy ki-mi szív még azzal, amivel épp te is :-D
Kettő ügyviteli szoftver fejlesztésével foglalkozó céget is ismerek belülről, de egyiküknek sem ez az előtörténete. Igaz, nem Karcsika és társa Betétitársaság szintű cégek. Amiről írsz inkább azokra jellemző.
Egyikük még ma is Delphiben nyomja, nem mernek belevágni az újraírásba. Magyarországi betegség ez a szemlélet.
A másik licencel egy nem magyar fejlesztésű keretrendszert és ott adott a .net C# alap. Mindkettő alap telepítéssel és opcionális modulokkal kielégíti minden ügyfelük igényét, amiből elég sok van. Az utóbbi folyamatvezérlést is tud. Nem állítom, hogy nem lehet jogos igény egyedi szoftverre ebben a kategóriában, azt viszont feltételezem, hogy az a magyar cég aki ilyenért hajlandó pénz kiadni valószínűleg visszafele számlázásért, számkozmetikáért és hasonló hungaricum szolgáltatásokért hajlandó megfizetni az egyedi szoftver jelentős extra költségét. :-)
Nekem nem az a gondom, hogy nem támogatnak több platformot és többféle DB backend-et. Hanem az, hogy amit támogatnak, azt is csak amatőr szinten, sokszor nem jól működik, és ha baj van, a mai napig (a legtöbben) az ügyfél hatáskörébe tartozó dologra (hardver, OS, hálózat, internet) fogják a működési hibát. Ráadásul nem akarnak a korral haladni, pl. ez a "VM-ben nem működik, pont", meg az MSSQL-ből akkor váltanak csak egyel újabb verzióra, mikor végképp működésképtelenné válik az ősrégi, általuk használt verzió (pl. SQL2005-ről SQL2014-re áttérés, mikor az SQL2019 volt már az aktuális bő egy éve).
A legtöbb fejlesztő - már elnézést, de - sem a fejlesztéshez sem a fejlesztett rendszer szakmai (ügyviteli) részéhez nem ért. Kavar valamit, és előbb utóbb vagy sikerül valamennyire, vagy a felhasználó belenyugszik a hibába.
Ezért sem tartom problémának, hogy szépen zárnak be a "kódoló iskolának" csúfolt fizetős, rutin kód begépelés tanító szakkörök.
Friss élmény: webshop hirtelen nem küld levelet semmiről. Teszteljem. Regisztrálók fiókot, nem kapok róla e-mail-t. Belépni nem tudok a friss regisztrációval. Fejlesztő: a reg-ről nem megy e-mail, minek, hisz én regisztrálta, tudom, hogy regisztráltam, és azért nem tudok belépni, mert 25 karakteres jelszót adtam meg és 24 a limit. Mondom miért nem szól, hogy túl hosszú a jelszó? Hát, szerinte (!) szólt volna ha begépelem kézzel, de én kopi-pasztéztam valószínű jelszószéfből, ami nagyon rossz gyakorlat, a jelszószéfeket el kell felejteni, és akkor nem szól, nincs form köldés előtti verify. De a regnél lecsípja a 24 feltti karaktereket és az első 24-gyel be tudok lépni. Amikor belépés van, akkor persze nem csípja le a 24 felettit, úgy veti össze a regisztrációkor lecsípottal. Mikor jelzem, hogy mindig kellene validálni a mezőt, és túl kevés a 24 karakter manapság, akkor kikel magából, hogy ez neki mennyi munka lenne, amit senki sem fog kifizetni.
Persze az e-mail azért nem ment el, mert sima PHP mail() függvénnyel küldték, egy levelezésre egyáltalán fel nem készített webszerverről, nem a megadott feladó címmel és nem volt SPF rekord a mail szerver által használ (sehol máshol nem létező) tartományra... De az sem az ő hibájuk, hanem mit variál mindig a nyavajás Google a levelezéssel... Mikor felvetem, hogy lehetne PHP mailer csomag, akkor újabb felháborodás, hogy már a sima PHP verziókat is nagyon nehéz követni, nem még, hogy ilyen plusz csomagokra is figyelniük kelljen, ki fogja ezt kifizetni.
Ráadásul nem akarnak a korral haladni, pl. ez a "VM-ben nem működik, pont"
Ezt en nem is ertem, hol a pek faszaban kene futtatni egy ugyviteli rendszert, ha nem VM-ben? Nehogy mar bare metal kelljen egy konyveloszoftver ala, mert mindjart sirva fakadok.
De ha van ilyen szoftver, szívesen veszem az infót
Pedig van :) Az eVIR nem Wndowson készül, Linux szerveren fut és PostgreSQL-t használ. A legtöbb ügyfél az inkább előfizet a felhős szolgáltatásra, de van sok olyan felhasználónk is, akiknél helyben telepített fizikai gépre vagy virtuális gépre került. Ahol biztosan fut ügyfeleknél virtualizálva, az Xen, Proxmox és Hyper-V alatti Debian.
https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer
Ez érdekes! Az sg.hu oldalán egyetlen komment sincs, itt kommentálják rendesen a cikket. Más cikkeknél sincsenek kommentek. Ennyire érdektelen ma már az egykor szebb napokat látott supergamez, vagy csak bekrepált a fórummotorjuk és nincs idejük javítani? Sőt még arra sincs idejük, hogy ez esetben kivegyék a cikkek alól a Nem érkezett még hozzászólás. Legyél Te az első! szöveget.
Hozzászólások
Amilyen a szoftver(ek), olyan a részvény. :D
Gondoltam indítok egy faszsági versenyt, de Hajbi már a nevezéskor meg is nyerte.
Rég láttam utoljára, de akkor valami hihetetlen erőforrás zabáló monstrumnak tűnt. Bizonyára piaci rést töm, hogy így is sikeres.
lof*t. ha a marketing mukodik, a cegek megveszik, sikeres. hogy is volt a masik szalban a cpanel-lel? oh wait :)
en nem felek, hogy azt a 100 misit ne hajtanak be az ugyfeleken :) (amugy meg egy "jobb" uj auto ara, kvazi nevetseges tetel)
Oké, nem tudom, mekkora a cég kapitalizációja, de emlékeim szerint tizenhuszonakárhány éve a hazai KKV-knek nem sok olyan ügyviteli rendszer volt a piacon, ami naprakészen megfelelt az adóhivatal épp aktuális bürokráciájának.
Egy kozepes Rolls Royce kijon belole. Egy "jobb" mar nem annyira :)
911 turbo S kabrio 185k+ EUR. hozzadobsz 27% afat, mindjart megvan a 100kk+ HUF.
De ha hasznaltban utaznal: https://suchen.mobile.de/fahrzeuge/search.html?c=Cabrio&cn=DE&isSearchR…
Szoval ja. :)
A szoftveren kívül nem kapcsolódik a hírhez, csak beírom ide tanulságnak, más ne járjon így.
Kulcs-Soft VM-ben futott Windows 10 OS-en, ESXi-n, 5 éve. Az ESXi host elment nyugdíjba, az új szerveren Proxmox 8 van.
VM átmásol, driver rendbe tesz, minden szuperül működik, kivéve a Kulcs-Soft. 13-as hiba, nem sikerült a licenc érvényesítése. Ügyfélszolgálat: töröljük a szoftvert az új gépen, az eredeti gépről csináljunk mentést (a szoftverből), deaktiváljuk a licencet az eredeti gépen, telepítsük újra az új gépen, töltsük vissza a mentést, adjunk meg a licencet, működni fog. Nem így lett.
Telepítettünk egy vadi új VM-et Win10-el, arra a programot, betöltöttük a mentést, licencet adtunk neki: 13-as hiba.
Újabb vadi új VM, immár minden virtuális hardvert (amit csak lehet) ugyan az a Proxmox-on, mint ESXi-n volt (LSI SAS, VMXNET3 NIC, stb., nyilvámn így is csak hasonló, nem ugyan az), program telepít, adatbázis visszatölt, licenc odaad: 13-as hiba.
Ügyfélszolgálat: pedig annak mennie kellene. Egyébként Ők nem tudják mi a 13-as hiba oka. Mondom az üf-nak: nekik megvan a forráskód, csak tudják a saját programjukról, hogy milyen esetben ír ki 13-as hibát...
Munkatársam véletlenül elkottyantotta a kihangosított telefon mellett, hogy az egész egy VM-ben fut. Ügyfélszolgálat azonnali reakciója: ja! azt nem támogatjuk, nem tudunk segíteni a hiba megoldásában, tessék fizikai gépre tenni. De mondom 5 éve VM-ben futott. Nem tudunk segíteni, viszont hallásra.
Szégyen szemre kellett vinnünk egy mini PC-t a vadi új virtualizációs szerver mellé, amin ez a nyomorult program fut (már csak nem egy folyton ki-be kapcsolt munkaállomásra tesszük).
Nyilván valami hardver azonosítót figyel a licencelés miatt (ez azért mekkora gáz már 2024-ben!), és a Proxmox/qemu VM-ben nem azt olvasta ki, amit szeretett volna.
Még egy apró adalék: az eredeti gépen a programot elindítva azt írja: aktiválva. Felhívtuk az ügyfélszolgálatot, nem lehet az a gond, hogy a deaktiválás ellenére aktiválva van az eredrti helyen? Válasz: a deaktivált program újbóli elindítás esetén automatikusan aktiválja magát... Nesze neked kiszámíthatóság.
A lényeg hogy fizess! :D
A CPU típust próbáltatok változtatni? Hány CPU magot/socketet adtatok a windowsnak?
Régen voltak ilyen phenom X3 nevű AMD-s csodaprocik aminél az SQL2k szerver telepítése folyamatosan elhasalt és csak egy hibakódot adott vissza. Nagy nehezen kiderítettem, hogy csinál egy ellenőrzést telepítéskor és mivel 2 hatványa a magszám(vagy valami hasonló) ezért nem megy át a teszten. BIOSban vagy Windowsban 1 mag letilt és viola megy a telepítés...
Elsőre az eredeti működő VM-et másoltuk át az új host-ra, amiben addig működött a program.
Egyébként mindig kettő hatványa számú magot adunk (nem is tudom hogyan alakult ez ki, 6, meg 12, meg ilyenek valamiért nem jutottak soha eszembe), ráadásul sima 1 socket felállásban ilyen egyszerű feladatra, szóval nincs NUMA meg ilyenek. Úgy emléxem 1 socket, 4 mag, 8 GB memória van konfigurálva.
Micsoda? Milyen igenyes mernoki munka van itt, keremszepen :D
vm.conf -ba ennyi kellett volna:
uuid-t meg a vmware-ből így nyered ki:
Get-VM <vm_name> | %{(Get-View $_.Id).config.uuid}Gábriel Ákos
Valójában csak ennyit ellenőrizne ez a szoftver?
De ha ennyi a másolt VM felélesztése, az még mindig nem magyarázza, hogy egy vadi új telepítés és érvényes licenc-el aktiválás miért nem sikerül.
Ráadásul egy ugyan így, de fizikai gépre frissen telepített rendszer meg simán működik mindenféle extra nélkül (probléma mentes aktiválás után).
Egyébként ki tudom próbálni, mert megvan az eredeti szerver, érintetlenül. Ahogy időm engedi, tesztelem!
konkrétan ezzel a szoftverrel nem teszteltem de a "system id" másolása az ennyi.
ezen kívül még a vm mac-jét is másolnám.
a kódot nyilván nem ismerem de simán lehet hogy van egy rész ami a már aktivált szoftver "érintetlenségét" ellenőrzi és van egy másik ami még az aktiválatlan szoftverhez húzza be az aktivációt.
Gábriel Ákos
"ja! azt nem támogatjuk, nem tudunk segíteni a hiba megoldásában, tessék fizikai gépre tenni."
Ebbe én is belefutottam, mondtam is, hogy ja bocs, rosszul mondtam, az fizikai vason van, összekevertem egy másikkal.
(Ha már viccelődünk, viccelek én is.)
Gondoltam indítok egy faszsági versenyt, de Hajbi már a nevezéskor meg is nyerte.
Usecase: rendszergazda klónozza a wm-et,majd valamiért mindkettőben dolgoznak átmenetileg, vagy a klónozást követően még készül számla a régiben. Így azonos számlaszám mögött lehet különböző tartalom. A NAV nem fogadja be. Ügyfél visít. Na ez lenne a nagyobb gond, mert a new branch óta akár több ezer számla is elkészült.
sg.... Az még él? Időnként szembe jön.
Valaha jó volt. Szar látni így élettelenül, kihaltan.
Itt is itt van: https://telex.hu/gazdasag/2024/02/20/tiltott-piaci-manipulacio-kulcs-sz…
"Sose a gép a hülye."
Vegyük észre, hogy ez egy konyhavállalkozás volt, az újpalotai panelből indult (nem dzsentri volt). Szépen ment felfelé, sok cégnek példaértékű lehetne a növekedés. Az újgazdagok finomságait majd a következő generáció fogja vinni, a mostani sztárallűröknek hódol: Ferrari klub elnöke, golfklub elnöke és a biztonsági őr vitte a gyerekeket iskolába. Szerintem a tágadd ismerettségi körében sem volt még részvényes, pláne hogy ő bocsásson ki részvényeket. A tőke 90%-a az ő kezében van, látszat részvényeskedés. Ez a mostani játék pont nem jött be, 100m-t azért kidob magából és tanul belőle. Annyira biztos példaértékű mint a Musk és Bezos félék.
Hát, a cikk szerint nem tanult belőle. Ez már a második eset, az előző 30 millióba fájt neki.
Ha egyszer megcsinálod, akkor lehet véletlen. Másodikra már nehezen hiszik el.
...úgyis jönnek...
Ez az a Kulcsár, aki a yt-on ilyen short videókban oszt cégvezetési bölcsességeket? Kissé lábrázásom van tőle, hogy mindenféle szempontot felsorol a sikerhez, csak épp a termék minőségét nem :-(
yes, ő az
Jo, de sikeres?
Egyaltalan nem biztos, hogy a business modelled a minosegen alapszik.
Az egy dolog hogy yt-n okos, de amúgy bruttó 500.000HUF körül árulja a vállalkozói zsenialitását.
KoviX
Bocs, újpesti.
Azt is vegyük észre, hogy a BÉT-en olyan könnyű manipulálni a kis részvények árfolyamait (záróár beállítás, stb), hogy én is tuti okoztam a bagatell vásárolgatásaimmal olyat véletlenül, ami nap végén a bet.hu főoldalára került (napi top min / max). Ettől még szemétség, de a kis piacon annyira triviális, hogy minimálbért megforgatva lehet itt olyan híreket generálni, hogy hajjajj :)
Van egy verrel es verejtekkel szerzett tapasztalatom: amelyik szerverprogram csak es kizarolag windowson fut, azt messzirol el kell kerulni.
A kulcs-szoftot sikerult a multban elkerulni. Mondjuk az arazasa is segitett, de remelem en is:)
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Ezt én is osztom, de hazai ügyviteli szoftverek között nem sok lehet (én nem tudok egyet sem), amit nem Windows-on, összekattintgatós fejlesztő rendszerben írtak, Windows-only kivitelben, sokszor MSSQL-only DB-vel.
Az is jó, mikor mondjuk (a Kulcs-Soft-hoz hasonlóan) Firebird a DB szerver, de a Linux-os üzemelést nem támogatja a SW gyártója. Vagy MSSQL, Express is jó, de ha Linux-ra tennénk 17-es vagy újabbat, akkor nem adnak supportot az egyébként Windows-only klienshez, mert biztos a Linux-on futó DB miatt van minden baja.
De ha van ilyen szoftver, szívesen veszem az infót, és a jövőben javaslom az ügyfeleknek, hogy legalább a saját életem könnyítsem.
P.s.: eszembe jutott, hogy egyet tudok, ami MySQL DB-vel működik (így Linux-on is mehet a DB), de az olyan szar, hogy ez sem segít rajta.
> De ha van ilyen szoftver, szívesen veszem az infót, és a jövőben javaslom az ügyfeleknek, hogy legalább a saját életem könnyítsem.
Nalam a kenyszermegoldas felhos, havidijas lett. Szoval nincs telepitve lokalisan.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
en el tudom kepzelni, hogy ez gazdasagi dontes. ha minden platform minden adatbazis kezelojet tamogatnak, a megnovekedett szakember igeny miatt a termek kevesbe lenne versenykepes.
neked aztan fura humorod van...
Rettenetesen megnonek a koltsegek, ha a tamogatas nem annyit jelent, hogy "Jozsi egyszer mar majdnem sikeresen futtatta". Ha valos termektamogatast nyujt, beszallitoi/parneri szerzodesekkel rendelkezik marketinghez, ertekesiteshez, szallitashoz, deploymenthez, hibak felderitesehez (akar sima hibajegy irashoz - ugye nem gondoljuk, hogy ez ingyen van?), illetve rendszeresen teszteli a (helyes mukodes, karakterisztika, security stb.) a kiadasait a kulonbozo platformokon, kulonbozo 3P megoldasokkal, akkor siman tobbszoroset kolti el PLCM-re.
Ez egy kicsi, de legalabb nem gazdag piacon nem biztos, hogy a siker kulcsa.
Ez szepen hangzik a valosag ezzel szemben az, hogy excel makrokent indul. Majd Visual Basic-be torkollik, utana jon az MS Access, majd mar vesznek fel arcokat, mert kezd nagy lenni a ceg, es utana hatalmas code refaktoring utan kikotnek .NET + MSSql -nel.
Most hogy haladni kell a korral, esetleg Azureban futtatjak.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
nekem amit te irsz, az egy cegben belul fejlesztett programnak tunik, ami segiti a ceget, de a cegnek nem ez a profilja.
ezzel szemben, ha egy cegnek maga a program a profilja, akkor az nem excel makrokat arul, legalabbis mostanaban, 20 eve meg lehet.
persze mindig lehetnek kivetelek, ezt belatom.
neked aztan fura humorod van...
A hazai gyártású ügyviteli szoftverek legalább 80% pontosan így jött létre, hogy valaki magának kezdte el csinálni, és mikor már elég sok munkát tettek bele, akkor döntöttek úgy hogy eladják másnak is, hogy visszajöjjön a befektetésből valami.
Ilyenkor persze kiderül, hogy egy random másik cég nem pont ugyan úgy működik, ahogy az eredeti fejlesztő cég, aztán így kiderül, hogy egy csomó dolog be van drótozva paraméterezés helyett, amit irtózat nehéz utólag átalakítani, a rendszer nem modulos, így nagyon nehéz különböző kiviteleket eladni a különböző igényekhez, stb. stb.
Tudok olyan szoftverről, aminél minden partnerhez saját support fejlesztő tartozott, aki a partner igényeit megvalósította, és ahány partner, annyi szoftver verzió élt egy időben, akár teljesen azonos verziószámmal, de tök különböző tartalom mellett... Meg voltak funkciók amiket többször fejlesztettek ki különböző partnerek igényeire, mert nem tudták, hogy az már másik partnernél megvalósult. Ez is egy olyan szoftverből nőtt ki, ami eredetileg saját felhasználásra készült.
A legszebb az ilyen sok ügyfélnek eladott motyóban az, amikor a DB-matató sql-ben ott figyel egy vagy több "...where foo.bar='masikügyfél'", vagy épp a binárisba bele vannak fordítva a használatra jogosult cégeknek az alapvető adatai - "természetesen" olvasható formában... Aztán ügyfélként csak vigyorogsz, hogy ki-mi szív még azzal, amivel épp te is :-D
akkor csak szerencses vagyok hogy ezt a 80%-ot nem ismerem, legfeljebb itt hallok felole.
neked aztan fura humorod van...
Kettő ügyviteli szoftver fejlesztésével foglalkozó céget is ismerek belülről, de egyiküknek sem ez az előtörténete. Igaz, nem Karcsika és társa Betétitársaság szintű cégek. Amiről írsz inkább azokra jellemző.
Egyikük még ma is Delphiben nyomja, nem mernek belevágni az újraírásba. Magyarországi betegség ez a szemlélet.
A másik licencel egy nem magyar fejlesztésű keretrendszert és ott adott a .net C# alap. Mindkettő alap telepítéssel és opcionális modulokkal kielégíti minden ügyfelük igényét, amiből elég sok van. Az utóbbi folyamatvezérlést is tud. Nem állítom, hogy nem lehet jogos igény egyedi szoftverre ebben a kategóriában, azt viszont feltételezem, hogy az a magyar cég aki ilyenért hajlandó pénz kiadni valószínűleg visszafele számlázásért, számkozmetikáért és hasonló hungaricum szolgáltatásokért hajlandó megfizetni az egyedi szoftver jelentős extra költségét. :-)
Nekem nem az a gondom, hogy nem támogatnak több platformot és többféle DB backend-et. Hanem az, hogy amit támogatnak, azt is csak amatőr szinten, sokszor nem jól működik, és ha baj van, a mai napig (a legtöbben) az ügyfél hatáskörébe tartozó dologra (hardver, OS, hálózat, internet) fogják a működési hibát. Ráadásul nem akarnak a korral haladni, pl. ez a "VM-ben nem működik, pont", meg az MSSQL-ből akkor váltanak csak egyel újabb verzióra, mikor végképp működésképtelenné válik az ősrégi, általuk használt verzió (pl. SQL2005-ről SQL2014-re áttérés, mikor az SQL2019 volt már az aktuális bő egy éve).
A legtöbb fejlesztő - már elnézést, de - sem a fejlesztéshez sem a fejlesztett rendszer szakmai (ügyviteli) részéhez nem ért. Kavar valamit, és előbb utóbb vagy sikerül valamennyire, vagy a felhasználó belenyugszik a hibába.
Ezért sem tartom problémának, hogy szépen zárnak be a "kódoló iskolának" csúfolt fizetős, rutin kód begépelés tanító szakkörök.
Friss élmény: webshop hirtelen nem küld levelet semmiről. Teszteljem. Regisztrálók fiókot, nem kapok róla e-mail-t. Belépni nem tudok a friss regisztrációval. Fejlesztő: a reg-ről nem megy e-mail, minek, hisz én regisztrálta, tudom, hogy regisztráltam, és azért nem tudok belépni, mert 25 karakteres jelszót adtam meg és 24 a limit. Mondom miért nem szól, hogy túl hosszú a jelszó? Hát, szerinte (!) szólt volna ha begépelem kézzel, de én kopi-pasztéztam valószínű jelszószéfből, ami nagyon rossz gyakorlat, a jelszószéfeket el kell felejteni, és akkor nem szól, nincs form köldés előtti verify. De a regnél lecsípja a 24 feltti karaktereket és az első 24-gyel be tudok lépni. Amikor belépés van, akkor persze nem csípja le a 24 felettit, úgy veti össze a regisztrációkor lecsípottal. Mikor jelzem, hogy mindig kellene validálni a mezőt, és túl kevés a 24 karakter manapság, akkor kikel magából, hogy ez neki mennyi munka lenne, amit senki sem fog kifizetni.
Persze az e-mail azért nem ment el, mert sima PHP mail() függvénnyel küldték, egy levelezésre egyáltalán fel nem készített webszerverről, nem a megadott feladó címmel és nem volt SPF rekord a mail szerver által használ (sehol máshol nem létező) tartományra... De az sem az ő hibájuk, hanem mit variál mindig a nyavajás Google a levelezéssel... Mikor felvetem, hogy lehetne PHP mailer csomag, akkor újabb felháborodás, hogy már a sima PHP verziókat is nagyon nehéz követni, nem még, hogy ilyen plusz csomagokra is figyelniük kelljen, ki fogja ezt kifizetni.
Ezt en nem is ertem, hol a pek faszaban kene futtatni egy ugyviteli rendszert, ha nem VM-ben? Nehogy mar bare metal kelljen egy konyveloszoftver ala, mert mindjart sirva fakadok.
jelen!
Van egy regi fizikai szerver, onmagaban tobbet fogyaszt, mint az osszes tobbi osszesen. Egy program miatt van fenntartva.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Pedig van :) Az eVIR nem Wndowson készül, Linux szerveren fut és PostgreSQL-t használ. A legtöbb ügyfél az inkább előfizet a felhős szolgáltatásra, de van sok olyan felhasználónk is, akiknél helyben telepített fizikai gépre vagy virtuális gépre került. Ahol biztosan fut ügyfeleknél virtualizálva, az Xen, Proxmox és Hyper-V alatti Debian.
https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer
Köszönöm, megnézem, hogy képbe kerüjek!
Amennyiben ilyen igényt kapunk, akkor ezt is javasolni fogom megnézésre, de az úgyfélnek kell tudni, milyen szolgáltatás készletet szeretne.
> P.s.: eszembe jutott, hogy egyet tudok, ami MySQL DB-vel működik (így Linux-on is mehet a DB), de az olyan szar, hogy ez sem segít rajta.
Melyik volt az?
pch
SB-soft online ügyviteli rendszer
"Firebird a DB szerver, de a Linux-os üzemelést nem támogatja a SW gyártója"
S...Tech? :)
Ez érdekes! Az sg.hu oldalán egyetlen komment sincs, itt kommentálják rendesen a cikket. Más cikkeknél sincsenek kommentek. Ennyire érdektelen ma már az egykor szebb napokat látott supergamez, vagy csak bekrepált a fórummotorjuk és nincs idejük javítani? Sőt még arra sincs idejük, hogy ez esetben kivegyék a cikkek alól a Nem érkezett még hozzászólás. Legyél Te az első! szöveget.
a kozossegepites humaneroforrast igenyel.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....