Olisi hienoa jos saisi porukan kasaan joidenka kanssa voisi suunnitella ja toteuttaa CRM asiakashallintasovelluksen. Tietenkään suunnittelusta ja toteutuksesta ei makseta palkkaa vaan sitten kun ohjelmisto on valmis ja sitä aletaan oikeasti myymään firmoille.
Oikeasti olen miettinyt sellaista kun tässä puoliksi työttämänä ollaan eikä oikein tällä it-alalla näitä hommia juurikaan ole, tälläinen olis oikeasti lottovoitto muutamalle työttömälle koodarille.
Sen työttömänä olo ajan voisi käyttää sijoituksena tulevaisuuteen tai vaikka opiskelujen ohessa :)
Onko tälläinen ihan hatusta vedetty ajatus? Itse työskentelen osa-aikaisena sukulaiseni firmassa ja tiedän heti muutamia yrityksiä jotka kiroavat näitä Logican ym isojen firmojen rahastusmeininkiä ja olisivat valmiita vaihtamaan CRM ja reskontratyökaluja jos vaihtoehtoja vain olisi.
Mites tää kilpailee näiden avoimien CRM -sovellusten kanssa? Ne on kuitenkin jo valmiita ja kehitystiimeissä on hieman enemmän porukkaa ja ehkä ensimmäiset tyyppiviat todettu ja korjattu?
Eli noitahan voi myös räätälöidä, jolloin myydään sitä räätälöintiä ja tuotetukea asiakkaille.
Muutaman kerran töissä tullut vastaan aloittelevia firmoja, joilla on ollut juuri kova hinku päästä kehittämään omia julkaisujärjestelmiä pienellä porukalla, ja uskotella, että (tietoturva-)ongelmien ilmaantuessa (jos sellaisia edes tulee) ne voidaan korjata tietenkin ilman aikaviivettä, koska muutahan työtä tässä ei tietenkään tehdä.
Julkkarit ovat olleet hienoja teknillisesti ja tukeneet kaikkea mahdollista (ja jos ei vielä niin nehän ovat olleet tietenkin skaalautuvia), kuitenkin ulkoasu ja käyttöliittymät ovat olleet perus-koodarikäyttiksiä, eli mystisiä tekstikenttiä parametreille on ollut ylläpitopuoli täynnä.
Eli suosittelen suosiolla ja lämpimästi tutustumaan ensitöikseen ihan valmiisiin ratkaisuihin, ja kehittämään sitten siinä sivussa jotain omaa tuotetta, jos se edes tuntuu enää sen jälkeen omastakaan mielestä järkevältä.
Muussa tapauksessa "työttömänä tehty" buginen ja ominaisuukseton crm ei välttämättä ole mikään tuottoisa sijoitus.
Olen kyllä tutustunut muutamaan valmiiseen ratkaisuun, SugarCRM ja vTiger ovat esimerkiksi yhdet, kyllä tietty se räätälöintikin Suomen oloihin sopivaksi on yksi vaihtoehto mutta minun ajatukseni olikin se että toteutettaisiin porukalla kokonaan uusi järjestelmä, ei mikään webbihässäkkä vaan ihan oikea työpöytäsovellus.
Ei se työttömänä tehty välttämättä ole buginen koska siinä pitäisi olla riittävästi aikaa eikä mitään suorituspaineita niinkuin liike-elämässä on, työttömänä ollessa on aikaa testailla ja korjailla vikoja ennenkuin sitä alkaa myymään.
Noita valmiita ratkaisuja voi kuka tahansa tarjota mutta sitä itse tehtyä ei.
No siis työttömyys ja bugisuus ei tässä liittynyt toisiinsa vaan se, että kun aloitetaan homma kokonaan nollista, niin alussa todennäköisesti voi olla "bugeja" ja ihan vääriä lähestymisiä aiheeseen, kun taas valmiit sovellukset ovat eläneet jo sen vaiheen yli, testausta on tehty useamman kuin 100 ihmisen voimin ja tyyppiviat nähty ja korjattu.
Tuo on ihan totta, silti se "oma" sovellus kiehtoo, kaippa se menee jossain vaiheessa ohi. Pitää tyytyä väsäämään vaan sellasia pikkujuttuja ihan harrastuksena...
Taipuisiko tuo freepascal+lazarus tuollaiseen Asiakas-, myynnin ja varastonhallintaan? Siihen mukaan vielä esim. PostgreSQL tietokanta.
Tuossa yhdistelmässä olisi ainakin se hyvä puoli että tuo freepascal kääntyy Windowsin lisäksi mukavasti myös Linuxille ja Macille ;-)
Olenko ymmärtänyt väärin vai eikös tuo Lazarus+freepascal yhdistelmä ole vähän kuin Delphi ja Delphiähän käytettiin ja käytetään vieläkin paljolti juurikin tuollaisten tietokantasovellusten tekemiseen.
Jotkut kyllä väittää että delphi olisi kuollut juttu ja toiset väittää että ei ole, kannattaako tuota freepascal+lazarusta harkita vakavasti?
Mielipiteitä?!
leipuri kirjoitti:
Jotkut kyllä väittää että delphi olisi kuollut juttu
Muistan hämärästi kuulleeni Delphistä jotain silloin 90-luvulla ku tutustuin ohjelmointiin.
En tiiä, kai se jotain kertoo, ettei mulla oo koneella yhtään Freepascalilla koodattua softaa...
Hmm... Ei taida olla minullakaan asennettuna lukuunottamatta omia harjoituksia. Ainakin freepascalia vielä kehitetään, wikipedian mukaan uusin versio freepascalista (2.4.4) olisi ilmestynyt 3kk sitten.
http://en.wikipedia.org/wiki/Free_Pascal
Mitä jos teet sen cobolilla. Samalla opit sitä ja työpaikka on taattu kun cobol-ammattilaiset eläköityy jatkossakin.
No perskules siinähän tuli se mun juttuni, cobol.
Ei vais, olen itse kiinnostunut tuosta freepascalista, se tuntuu jotenkin mun aivoille niin loogiselta ja ymmärrettävältä, tosin kuin c++ mitä olen myös tässä yrittänyt opetella.
btw. myös tuosta lazaruksesta on tullut uusi versio 5kk sitten.
http://en.wikipedia.org/wiki/Lazarus_(IDE)
Kyllä Pascal on ihan käypä kieli omaan käyttöön. Isompaan projektiin voi vain olla vaikea värvätä lisää väkeä, kun kieli on monelle outo.
leipuri kirjoitti:
Hmm... Ei taida olla minullakaan asennettuna lukuunottamatta omia harjoituksia. Ainakin freepascalia vielä kehitetään, wikipedian mukaan uusin versio freepascalista (2.4.4) olisi ilmestynyt 3kk sitten.
http://en.wikipedia.org/wiki/Free_Pascal
Lazarus on FreePascal:a käyttävä Delphimäinen IDE. Sen SVN-versio buildataan joka päivä. Uusin käyttää fpc 2.5.1. Bug tracker ja forum käy aktiivisena koko ajan eli on aika kaukana kuolleesta :)
Tietty eri asia sitten käytetäänkö sitä Suomessa, käsittääkseni ei juuri ollenkaan.
User137 kirjoitti:
Tietty eri asia sitten käytetäänkö sitä Suomessa, käsittääkseni ei juuri ollenkaan.
Olen sitten ilmeisesti yksi harvoista tien raivaajista täälä Suomessa. Tuli tässä sellainen idea mieleen että täytyy kokeilla asentaa Lazarus ja freepascal oman paikkakuntani kouluihin Ubuntu LTSP järjestelmään.
Täälä meilla opiskellaan tietääkseni pascal kielellä ohjelmoinnin alkeita ainakin ylä-asteella, lukiosta en ole varma. Opettajillekkaan tuo lazarus ei välttämättä ole mikään mahdottomuus, se on aika yksinkertainen IDE ja jopa Suomennettu vielä! (:
Siitä se sitten varmaan ajan kanssa alkaisi yleistymään.... (ehkä)
Toi on vaan loistava ympäristö siihen kun tehdään ohjelmia monille alustoille, lisäksi matala kynnys oppia.
Mites kun Yritystelen Contact Center sisältää valmiin tietokannan jossa on 500000 skandinaavista yritystä ja siinä on yksinkertinen CRM ja se on todella yksinkertainen ja ilmainen. Miten jaksat syöttää asiakkaat manuaalisesti mm. SugarCRM:n? Eli jos vastaavan saisi Internet-selainkäyttöisenä ja sellaisena, että muut käyttäjät tietää mitäkä asiakaat on käsitelty muiden työn tekijöiden osalta ettei samaan firmaan soiteta uudestaan kun sieltä on jo kieltäydytty ostamasta mitään.
Joskus koodailin SalesPower-nimisen myynnin ja markkinoinnin CRM-softan.
Väliportaana ollut firma kopsasi koodin ja lopuasiakas väitti sen itse tehneensä.
Softaa myytiin 47 eri maahan, jäi saamatta Sanomien tytäryhtiöltä koodaussaatava.
Homma tehtiin 1996-1997 Turbo-pascalilla, nyt se olisi simppeli rakentaa Delphillä.
Jos kiinnostusta löytyy, voisi aiheesta kai rakentaa hajautetun projektin.
Tietokannan olen myös kirjoitellut, verkkotietokanta, ei mikään hidas SQL.
Grez kirjoitti:
Mitä jos teet sen cobolilla. Samalla opit sitä ja työpaikka on taattu kun cobol-ammattilaiset eläköityy jatkossakin.
Cobol olisi kyllä oikeasti aika kannattava kieli opiskella, tosin sen rinnalla kannattaisi ottaa haltuun IBM:n DB2-tietokanta sekä joukko muita välineitä. Sen verran olen saanut sivusta seurata tuota Cobolin käyttöä, että pystyn kyllä väittämään, että se on höpöpuhetta, etteikö Cobolia vielä tänäkin päivänä käytettäisi. Taloushallinnon sekä pankki- ja vakuutusalojen puolella Cobolia käytetään oikein olantakaa ja onhan se kuitenkin juuri tämän tyylisin tehtäviin suunniteltu väline ja hyvä siinä. Usein myöskin väitetään, että Cobol-osaajia kaivataan vain vanhojen sovellusten ylläpitoon, mutta kyllä sillä Cobolilla kehitetään päivittäin uusiakin softia...
Mä tekisin J2EE:llä ja minulla on SHA 512+1024 bit encrypt lisenssi-avain-systeemi valmiiksi koodattu, joka tallentaa lisenssin .xml-tiedostoon, jossa on palvelimen IP-osoite, asiakkaantiedot ja palvelimen MAC-osoite joita verrataan xml-tiedostossa olevaan hash:in sillä tavalla, että palvelimen IP-osoitetta/MAC-osoitetta vaihtamalla ohjelma ei enää toimi ja myöskään kukaan ei tiedä hash:in laskentakaavaa joten oman lisenssi-avain-generaatorin tekeminen on mahdotonta, jos ei saa laskentakaavaa jostain eikä kukaan tiedä mitä kaikkia SHA/MD5 yms. salauksia on käytetty sekaisin ja missä järjestyksessä. Samoin minulla on jo kalliin lakimiehen tekemä Software License Agreement. Ohjelman voisi tehdä Atlassian Confluence Pluginina, jolloin voisi kehittää ehkäpä uuden lisenssi-avain-systeemin.
Ainiin, yksi vika tossa lisenssi-avain-systeemissä on. Jos asiakas ei deletoikkaan vanhaa lisence.xml-tiedostoa kun hän väitää vaihtaneensa palvelinta, ja sille tehdään uusi lisenssi-avain niin silloin se saa luvattomia asennuksia.
PS:
Miksi Plugarina Confluenceen? No siksi, että se olisi helppo markkinoida valmiille asiakkaille: http://www.atlassian.com/company/customers ; täällä: https://plugins.atlassian.com/plugin/home
Voin meinaan kokemukselta väittää, että projektilla on riskinä kaatua kilpailuun ja markkinointiin kun kukaan ei löydä tuotetta ja mm. Google AdWord -kampanjat maksaa helposti 50 € / päivä.
Miksi Confluencen käyttäjät haluaisivat ostaa helposti murrettavan snakeoil-plugarisi, kun tietoturvallisiakin tapoja tehdä lisenssi on olemassa?
Tuohon palvelinvaihtojutskaan voisit tietty tehdä niin että lisenssi uusituisi automaagisesti vaikka 14 päivän välein ja 28 päivän vanha lisenssi ei enää toimisi. Toki tuosta tulisi paskaa niskaan jos uusintasysteemi ei toimisi 14 päivään.
Grez kirjoitti:
Miksi Confluencen käyttäjät haluaisivat ostaa helposti murrettavan snakeoil-plugarisi, kun tietoturvallisiakin tapoja tehdä lisenssi on olemassa?
Tuohon palvelinvaihtojutskaan voisit tietty tehdä niin että lisenssi uusituisi automaagisesti vaikka 14 päivän välein ja 28 päivän vanha lisenssi ei enää toimisi. Toki tuosta tulisi paskaa niskaan jos uusintasysteemi ei toimisi 14 päivään.
Lisenssi-avain-systeemi on samallainen kuin Polarion ALM:ssä: http://www.polarion.com/
Ja alunperin kehitetty minun tekemään Polarion ALM -plugariin.
Lisenssi-avaimen murrettavuus ei vaikuta asiakkaiden osto halukkuuteen, vaan se haluaako asiakaat yleensäkkään CRM:n Confluenseen.
Confluencessa on parempi lisenssi-avain-systeemi kuin Polarionissa.
Voisin kokeilla koodailla TRUE Licenseen perustuvan lisenssi-avain-systeemin.
Jaa sori, luin että sitä lisenssisysteemiä myisit pluginina.
No joo, kieltämättä on aika se ja sama, että murtuuko se lisenssisysteemisi päivässä vai ei, kun useimmat tuollaisia ohjelmia käyttävät ei jaksa alkaa värkkäämään lisenssigeneraattoreiden kanssa.
Silti pisti huvittamaan kun väität ettei lisenssigeneraattoria ole mahdollista tehdä, vaikka toimintakuvauksesi perusteella se on hyvin helppoa.
Kerronpa nyt huvikseni, miten voit tehdä helposti sellaisen lisenssin, johon ei (nykytietämyksen mukaan) oikeasti ole mahdollista tehdä keygeneratoria*: Allekirjoitat lisenssin salaisella avaimellasi ja ohjelma sisältää julkisen avaimesi, jolla se tarkistaa lisenssin aitouden. Ei tarvitse mitään käärmeöljyä.
* paitsi jos joku varastaa salaisen avaimesi.
Grez kirjoitti:
Silti pisti huvittamaan kun väität ettei lisenssigeneraattoria ole mahdollista tehdä, vaikka toimintakuvauksesi perusteella se on hyvin helppoa.
Ymmärsitkö nyt varmasti miten se toimii?
Eli näin
LicenseServer.java lukee ensin xml-tidostosta muutujat.
<company></company>
<email></email>
<ip></ip>
<mac></mac>
<date></data>
<effective></effective>
Tekee näistä SHA512 hashin asiakkaan tietämättömässä järjestyksess jossa on perässä nk. suolaus.
Ja tästä uudestaan SHA1024 hashin jossa on uusi suolaus
Tämä hash on tallennettu xml-tiedostoon muutujaan
<hash></hash>
Eli ks. XML-tiedoston hashiä verrataan sitten if-lauseella LicenseServer.java tiedoston hashiin.
En tiedä miten helppoa on murtaa noi SHA-salaukset ja onko Java-koodi kännettynä mahdollista murtaa takaisin alkuperäiseen.
walkout_ kirjoitti:
Ymmärsitkö nyt varmasti miten se toimii?
Nähdäkseni ymmärsin ihan täysin miten se toimi. Tämä uusi viestisi vaan vahvisti käsitystäni.
walkout_ kirjoitti:
En tiedä miten helppoa on murtaa noi SHA-salaukset
SHA ei ole salaus eikä lisenssigeneraattorin tekemiseksi sitä tarvitse millään tavalla "murtaa".
walkout_ kirjoitti:
ja onko Java-koodi kännettynä mahdollista murtaa takaisin alkuperäiseen.
Java-koodi käännettynä on erittäin helppo muuttaa takaisin lähdekoodiksi. Obfuskaattorit tekee sen luettavuuden hankalammaksi, muttei suinkaan osaavalle mahdottomaksi. Ja vaikka ei pystyisikään, niin sen laskevan koodin voi hakkeri kopioida vaikka ihan käännettynä eli tavukoodina siitä ja lykätä sellaisenaan omaan lisenssigeneraattoriinsa. Ja vaikka kääntäisit natiivikoodiksi (JNI yms), niin silti se on melko helppoa siitä kaivaa. Tai vaikka teet ovelia harhautuksia, niin näppärä kaveri selvittää nekin.
Tuollainen "security through obscurity" lähestyminen ei koskaan ole hyvästä, varsinkaan kun vuosien tieteellisen tutkimuksenkin jälkeen varmoina pidettyjä keinojakin on olemassa.
Grez kirjoitti:
Nähdäkseni ymmärsin ihan täysin miten se toimi. Jälkimmäinen viestisi vahvisti vaan käsitystäni.
Java-koodi käännettynä on erittäin helppo muuttaa takaisin lähdekoodiksi. Obfuskaattorit tekee sen luettavuuden hankalammaksi, muttei suinkaan osaavalle mahdottmaksi. Ja vaikka ei pystyisikään, niin sen laskevan koodin voi hakkeri kopioida vaikka ihan käännettynä eli tavukoodina siitä ja lykätä sellaisenaan omaan lisenssigeneraattoriinsa. Ja vaikka kääntäisit natiivikoodiksi (JNI yms), niin silti se on melko helppoa siitä kaivaa. Tai vaikka teet ovelia harhautuksia, niin näppärä kaveri selvittää nekin.
Tuollainen "security through obscurity" lähestyminen ei koskaan ole hyvästä, varsinkaan kun vuosien tieteellisen tutkimuksenkin jälkeen varmoina pidettyjä keinojakin on olemassa.
Minkälaista systeemiä sitten suosittelisit, joka olisi tietoturvallisempi.
En tosin ole koskaan nähnyt systeemiä jota ei olisi jo murrettu. Kaikki softat yleensä pystyy warettaan.
walkout_ kirjoitti:
Minkälaista systeemiä sitten suosittelisit, joka olisi tietoturvallisempi.
Kirjoitin 29.11.2011 02:08:58:
Grez kirjoitti:
Kerronpa nyt huvikseni, miten voit tehdä helposti sellaisen lisenssin, johon ei (nykytietämyksen mukaan) oikeasti ole mahdollista tehdä keygeneratoria*: Allekirjoitat lisenssin salaisella avaimellasi ja ohjelma sisältää julkisen avaimesi, jolla se tarkistaa lisenssin aitouden. Ei tarvitse mitään käärmeöljyä.
* paitsi jos joku varastaa salaisen avaimesi.
walkout_ kirjoitti:
En tosin ole koskaan nähnyt systeemiä jota ei olisi jo murrettu. Kaikki softat yleensä pystyy warettaan.
Toki sitä softaa puukottamalla pystyy suojauksen poistamaan itse softasta. Kuten sanoinkin, tuo edellä mainitsemani ratkaisu estää "keygeneraattorin" tekemisen. Se ei kuitenkaan estä softan muuttamista niin, että se ei tarvitse ollenkaan lisenssiä.
walkout_ kirjoitti:
minulla on SHA 512+1024 bit encrypt lisenssi-avain-systeemi valmiiksi koodattu -- Samoin minulla on jo kalliin lakimiehen tekemä Software License Agreement.
Onneks alotat niistä oleellisimmista osista...
Miten musta tuntuu vähän siltä että tää walkout_ ei nyt keskity aivan olennaiseen. Mitä jos koodaisit sen softan ensin ja sitten leikkisit "lisenssi-avain-systeemeillä".
Lumpio- kirjoitti:
Miten musta tuntuu vähän siltä että tää walkout_ ei nyt keskity aivan olennaiseen. Mitä jos koodaisit sen softan ensin ja sitten leikkisit "lisenssi-avain-systeemeillä".
Ihan miten vaan mutta ohjelmaa ei voi pistää ainakaan jakoon jos ei ole lisenssisysteemiä.
Mut jo jos alan koodaan softaa niin en mä aluksi laita mitään lisenssisysteemiä siihen ennen kuin se on release versio.
Ja miten musta tuntuu, että tämä keskustelu on jo käyty ennenkin tuolla Kuhan puolella?
Teuro kirjoitti:
Ja miten musta tuntuu, että tämä keskustelu on jo käyty ennenkin tuolla Kuhan puolella?
Keskustelu on käyty Kuhan puolella aiemmin mutta se taisi mennä minun osalta överiksi.
Mutta jos mennään asiaan niin kannattaako ylipäätään koodailla maksullinen CRM, koska kilpailua on ja ajatellen, että Atlassian Confluence on kallis ylläpitää (tarvitaan vähintään virtuaalipalvelin) ja sen lisenssimaksu on kallis. Miksi en voi asentaa asiakkaalle mm. SugarCRM:ää ja pyytää hostauksesta vaikka 20 € / kk. Tietoturvariskit olisi minimaaliset, koska palvelimelleni pääsisin vain minä SSH-yhteydellä ja siellä on Suhosin Hardened PHP. Eli nk. Fully Managed Hosting tai SaaS.
Triton kirjoitti:
Grez kirjoitti:
Mitä jos teet sen cobolilla. Samalla opit sitä ja työpaikka on taattu kun cobol-ammattilaiset eläköityy jatkossakin.
Cobol olisi kyllä oikeasti aika kannattava kieli opiskella, tosin sen rinnalla kannattaisi ottaa haltuun IBM:n DB2-tietokanta sekä joukko muita välineitä. Sen verran olen saanut sivusta seurata tuota Cobolin käyttöä, että pystyn kyllä väittämään, että se on höpöpuhetta, etteikö Cobolia vielä tänäkin päivänä käytettäisi. Taloushallinnon sekä pankki- ja vakuutusalojen puolella Cobolia käytetään oikein olantakaa ja onhan se kuitenkin juuri tämän tyylisin tehtäviin suunniteltu väline ja hyvä siinä. Usein myöskin väitetään, että Cobol-osaajia kaivataan vain vanhojen sovellusten ylläpitoon, mutta kyllä sillä Cobolilla kehitetään päivittäin uusiakin softia...
Pitää paikkansa. Vakuutusyhtiöiden ja monen pankinkin vanhat sovellukset on koodattu Cobolilla, monissa tosin melko oudolla tavalla literaalivakioita käyttäen. Esimerkiksi Tapiola-Ryhmän valtaosa softista suurkonepuolella on kirjoitettu makkarakoodina Cobolilla. Valtaosalla nykykoodaajista ei ole valmiuksia taantua Cobolin tasolle, joskin rintamalla alkaa olemaan imua osaajista.
Aihe on jo aika vanha, joten et voi enää vastata siihen.