Hei,
Olisi kysyttävää JSON-datan lukemisesta REST:in yli, koska nyt sovelluksessani ks. data latautuu ärsyttävän hitaasi vaikka ohjelmisto lataisi vain 100 riviä per sivu kerrallaan.
Esim. tietokantasovelukissa SQL:llä saada ladattua vaikka 10000 riviä todella nopeasti ilman mitään sivustusta.
Vosiko tämä johtua alla olevasta tavasta ladata JSON-dataa?
// $phpNative['issues'] on json_encodattu data itse JSON-stringistä, joka on ladattu REST:in yli itse emoohjelmalta. foreach ($phpNative['issues'] as $key => $value) { //jotain koodia }
Miten korjaisin ongelman?
walkout_ kirjoitti:
Vosiko tämä johtua alla olevasta tavasta ladata JSON-dataa?
// $phpNative['issues'] on json_encodattu data itse JSON-stringistä, joka on ladattu REST:in yli itse emoohjelmalta. foreach ($phpNative['issues'] as $key => $value) { //jotain koodia }
Voisi. Riippuen mitä tämä "//jotain koodia" sisältää. Googlauksella löytyy kyllä miten nappaat vaikkapa millisekunnit talteen ja joilla yksinkertaisella miinuslaskulla selvität kuinka paljon aikaa kuluu mihinkin toimintoon.
walkout_ kirjoitti:
Miten korjaisin ongelman?
Korjaamalla ja optimoimalla koodia.
Onko siis niin, että PHP-koodissa haet dataa toiselta palvelimelta?
walkout_ kirjoitti:
Vosiko tämä johtua alla olevasta tavasta ladata JSON-dataa?
Jos se ”tapa” tarkoittaa foreach-silmukan käyttöä, niin se nyt ei itsessään ole ongelma. Tietysti jos silmukassa on sisällä jotain hidasta, se voi olla ongelma.
Oletko yhtään debugannut, mikä siinä kestää? Jos vaikka laitat lokiin aikaleimoja, voit näistä laskea, paljonko koodin eri osissa kuluu aikaa. Yleisesti ottaen tiedon siirto verkossa on paljon hitaampaa kuin tiedon käsittely, eli ihan se REST-pyyntö on todennäköisin pullonkaula.
Eli yksinkertainen ajanotto tapahtuu näin:
<?php $t0 = hrtime(true); $data = rest_pyyntö(); $t1 = hrtime(true); log_debug(sprintf("Pyyntö: %.6f s", ($t1 - $t0) / 1e9));
Tämän voi vaikka pyöräyttää funktioon tai luokkaan, että saa yhdellä rivillä lisättyä uusia aikapisteitä. Ota aikaa ainakin REST-pyynnöstä ja foreach-silmukasta ja myös ajasta ennen, välissä ja jälkeen, ettei mene mitään tärkeää ohi.
Tässä koko koodi mitä se foreach-looppi ajaa:
$i = 0; foreach ($phpNative['issues'] as $key => $value) { $json['issues'][$i]['id'] = (integer) $value['id']; $json['issues'][$i]['avatar'] = $value['fields']['issuetype']['iconUrl']; $json['issues'][$i]['type'] = $value['fields']['issuetype']['name']; $json['issues'][$i]['key'] = $value['key']; $json['issues'][$i]['summary'] = $value['fields']['summary']; //$json['issues'][$i]['description'] = $value['fields']['description']; $json['issues'][$i]['project'] = $value['fields']['project']['name']; $json['issues'][$i]['assignee'] = $value['fields']['assignee']['displayName']; $json['issues'][$i]['creator'] = $value['fields']['creator']['displayName']; $json['issues'][$i]['status'] = $value['fields']['status']['name']; $json['issues'][$i]['priority'] = $value['fields']['priority']['name']; $timespent = (integer) $value['fields']['timespent']; $json['issues'][$i]['timespent'] = $timespent / 3600; $json['remotesummary'][0]['timespent'] += $timespent / 3600; $json['remotesummary'][0]['summary'] = $total; $qsh = hash('sha256', "GET&/rest/api/2/issue/".$value['key']."/worklog&"); $uriWorklog = 'https://'.$customer['domain']."/rest/api/2/issue/".$value['key']."/worklog"; try { $clientWorklog = new Zend_Http_Client($uriWorklog, $config); } catch (Zend_Uri_Exception $e) { $json['success'] = false; $json['msg'] = $e->getMessage(); } $clientWorklog->setHeaders(array( 'Content-type' => 'application/json; charset=utf-8', "Host" => $customer['domain'], "Accept" => "application/json", 'Authorization' => 'Bearer '.$access_token )); $clientWorklog->setMethod(Zend_Http_Client::GET); $responseWorklog = $clientWorklog->request(); $bodyWorklog = $responseWorklog->getBody(); try { $phpNative = Zend_Json::decode($bodyWorklog); } catch (Zend_Json_Exception $e) { $json['success'] = false; $json['msg'] = $e->getMessage(); } $obj = array(); foreach ($phpNative['worklogs'] as $key => $value) { if ($worklogsauthor==null) { $doubleTimeSpent = (float) $value['timeSpentSeconds']; if (isset($obj[date('m-d-Y', strtotime($value['started']))])) { $oldTimeSpent = (float) $obj[date('m-d-Y', strtotime($value['started']))]; $doubleTimeSpent += (float) $oldTimeSpent; } else { } $obj[date('m-d-Y', strtotime($value['started']))] = (float) $doubleTimeSpent; $json['issues'][$i][date('m-d-Y', strtotime($value['started']))] = $doubleTimeSpent / 3600; $json['remotesummary'][0][date('m-d-Y', strtotime($value['started']))] += $doubleTimeSpent / 3600; } else if ($worklogsauthor=='null') { $doubleTimeSpent = (float) $value['timeSpentSeconds']; if (isset($obj[date('m-d-Y', strtotime($value['started']))])) { $oldTimeSpent = (float) $obj[date('m-d-Y', strtotime($value['started']))]; $doubleTimeSpent += (float) $oldTimeSpent; } else { } $obj[date('m-d-Y', strtotime($value['started']))] = (float) $doubleTimeSpent; $json['issues'][$i][date('m-d-Y', strtotime($value['started']))] = $doubleTimeSpent / 3600; $json['remotesummary'][0][date('m-d-Y', strtotime($value['started']))] += $doubleTimeSpent / 3600; } else { if ($value['author']['displayName']==$worklogsauthor) { $doubleTimeSpent = (float) $value['timeSpentSeconds']; if (isset($obj[date('m-d-Y', strtotime($value['started']))])) { $oldTimeSpent = (float) $obj[date('m-d-Y', strtotime($value['started']))]; $doubleTimeSpent += (float) $oldTimeSpent; } else { } $obj[date('m-d-Y', strtotime($value['started']))] = (float) $doubleTimeSpent; $json['issues'][$i][date('m-d-Y', strtotime($value['started']))] = $doubleTimeSpent / 3600; $json['remotesummary'][0][date('m-d-Y', strtotime($value['started']))] += $doubleTimeSpent / 3600; } else { } } } $i++; }
Eiköhän suurin pullonkaula ole tuossa http-requesti
Eli kaikki nämä:
$clientWorklog = new Zend_Http_Client($uriWorklog, $config);
Teet siis silmukassa 100 HTTP-pyyntöä ja mietit, miksi koodi on hidas. Siinäpä se vastaus jo on: 100 HTTP-pyyntöä on hidas. Tätä voisi ehkä nopeuttaa, jos saisit HTTP-yhteyden pidettyä auki, eli ”new Zend_Http_Client” pitäisi siirtää silmukan ulkopuolelle ja pitäisi laittaa sen asetuksiin keepalive, ja osoitetta voi vaihtaa metodilla setUri. Tosin ei kannata silti pidättää henkeä: pyynnöt vievät silti aikaa.
Lisäksi voisit optimoida koodia sillä tavalla, että esimerkiksi tuo 15 kertaa toistuva pala laskettaisiin valmiiksi ja käytettäisiin muuttujaa:
Sitä paitsi noissa if-lauseissa on näköjään kolmena kappaleena ihan täsmälleen sama koodi, eli koodia voisi tiivistää aika paljon yhdistämällä ehdot:
if ($worklogsauthor == null || $worklogsauthor == 'null' || $value['author']['displayName'] == $worklogsauthor)
Onko nuo muuten sellaisia rivejä, joita näytetään useita kertoja? Lähinnä mietin, että välimuistittaisit http-requestit esim. 10min - 60min (tai 1vrk, riippuen mihin noita käytetään) ajaksi paikallisesti, jolloin requesteja ei tarvitsisi ladata jokaisella sivulatauksella aina vain uudelleen.
Itse selvittäisin ensin että onko rajapinnasta mahdollista hakea noita silmukassa haettavia tietoja jollain pyynnöllä yhdellä kertaa.
Sitten jos ei, niin miettisin että onko oikeasti tarvetta muodostaa yhteenvetonäkymää jossa ne haetaan valmiiksi vai riittäisikö vaan listata issuet ja issuen valitsemisen jälkeen vasta haettaisiin yksityiskohdat.
Jos tuo on tarpeen niin sitten miettisin tuota leben ehdottamaa kakuttamista.
Toki jos käytettävä rajapinta sen sallii, niin voisit myös ajaa pyyntöjä asynkronisesti eli useita pyyntöjä käyntiin samanaikaisesti.
Jos teen koodille näin kuin alla niin pelkät issuet latauttuu hetkessä:
$i=0; $json['remotesummary'] = array(); $clientWorklog = new Zend_Http_Client(); foreach ($phpNative['issues'] as $key => $value) { $json['issues'][$i]['id'] = (integer) $value['id']; $json['issues'][$i]['avatar'] = $value['fields']['issuetype']['iconUrl']; $json['issues'][$i]['type'] = $value['fields']['issuetype']['name']; $json['issues'][$i]['key'] = $value['key']; $json['issues'][$i]['summary'] = $value['fields']['summary']; //$json['issues'][$i]['description'] = $value['fields']['description']; $json['issues'][$i]['project'] = $value['fields']['project']['name']; $json['issues'][$i]['assignee'] = $value['fields']['assignee']['displayName']; $json['issues'][$i]['creator'] = $value['fields']['creator']['displayName']; $json['issues'][$i]['status'] = $value['fields']['status']['name']; $json['issues'][$i]['priority'] = $value['fields']['priority']['name']; $timespent = (integer) $value['fields']['timespent']; $json['issues'][$i]['timespent'] = $timespent / 3600; $json['remotesummary'][0]['timespent'] += $timespent / 3600; $json['remotesummary'][0]['summary'] = $total; /*$qsh = hash('sha256', "GET&/rest/api/2/issue/".$value['key']."/worklog"); $uriWorklog = 'https://'.$customer['domain']."/rest/api/2/issue/".$value['key']."/worklog"; try { $clientWorklog->setUri($uriWorklog); $clientWorklog->setConfig($config); } catch (Zend_Uri_Exception $e) { $json['success'] = false; $json['msg'] = $e->getMessage(); } $clientWorklog->setHeaders(array( 'Content-type' => 'application/json; charset=utf-8', "Host" => $customer['domain'], "Accept" => "application/json", 'Authorization' => 'Bearer '.$access_token )); $clientWorklog->setMethod(Zend_Http_Client::GET); $responseWorklog = $clientWorklog->request(); $bodyWorklog = $responseWorklog->getBody(); try { $phpNative = Zend_Json::decode($bodyWorklog); } catch (Zend_Json_Exception $e) { $json['success'] = false; $json['msg'] = $e->getMessage(); } $obj = array(); foreach ($phpNative['worklogs'] as $key => $value) { if ($worklogsauthor==null) { $doubleTimeSpent = (float) $value['timeSpentSeconds']; if (isset($obj[date('m-d-Y', strtotime($value['started']))])) { $oldTimeSpent = (float) $obj[date('m-d-Y', strtotime($value['started']))]; $doubleTimeSpent += (float) $oldTimeSpent; } else { } $obj[date('m-d-Y', strtotime($value['started']))] = (float) $doubleTimeSpent; $json['issues'][$i][date('m-d-Y', strtotime($value['started']))] = $doubleTimeSpent / 3600; $json['remotesummary'][0][date('m-d-Y', strtotime($value['started']))] += $doubleTimeSpent / 3600; } else if ($worklogsauthor=='null') { $doubleTimeSpent = (float) $value['timeSpentSeconds']; if (isset($obj[date('m-d-Y', strtotime($value['started']))])) { $oldTimeSpent = (float) $obj[date('m-d-Y', strtotime($value['started']))]; $doubleTimeSpent += (float) $oldTimeSpent; } else { } $obj[date('m-d-Y', strtotime($value['started']))] = (float) $doubleTimeSpent; $json['issues'][$i][date('m-d-Y', strtotime($value['started']))] = $doubleTimeSpent / 3600; $json['remotesummary'][0][date('m-d-Y', strtotime($value['started']))] += $doubleTimeSpent / 3600; } else { if ($value['author']['displayName']==$worklogsauthor) { $doubleTimeSpent = (float) $value['timeSpentSeconds']; if (isset($obj[date('m-d-Y', strtotime($value['started']))])) { $oldTimeSpent = (float) $obj[date('m-d-Y', strtotime($value['started']))]; $doubleTimeSpent += (float) $oldTimeSpent; } else { } $obj[date('m-d-Y', strtotime($value['started']))] = (float) $doubleTimeSpent; $json['issues'][$i][date('m-d-Y', strtotime($value['started']))] = $doubleTimeSpent / 3600; $json['remotesummary'][0][date('m-d-Y', strtotime($value['started']))] += $doubleTimeSpent / 3600; } else { } } }*/ $i++; }
Sitten toinen kysymys on, että miten tallentaisin tämän jonnekkin ei siis mihinkään tietokantaan?
Koska siis worklogien summary ei toimi enää sen jälkeen oiken kun minulla on 100 issuen paginatio ja issuet nemee loputtomassa talukkokäyttöliittymässä yli 100 kpl.
Eli siis voisiko sen tallentaa sessiohin palvelimme niin että vaikka laitaisi 1000 issueta niin se laskee worklogien kokonain tuntimäärän oikein.
Miksei tietokantaan voi tallentaa?
Lebe80 kirjoitti:
Miksei tietokantaan voi tallentaa?
Siksi, että tämä on Appsi 3. osapoulen tuotteeseen ja ei olisi kiva tallennella käyttäjien dataa mihinkään tietokantaan. Sitä paitsi minulla on Appsissa päivittäinen varmuuskopitoini vain tiedostoille ja tietokanta ei voi varmuuskopioida jos en tee Virtuaalipalvelimelleni SQL-dumpin tekemiseen tarkoitettua croni-ajoa. Siis varmuuskopiointi on eräs 3. osapuolen pilvipalvelu, joka siis ei tue suoraa varmuuskopiointia mihinkään tietokantaan.
Myöskään jos varmuuskopiointi ei olisi olemassa en pääsisi tämän 3. osapuolen pilvi-tietoturva-ohjelmaan mukaan, saatikka Cloud Fortified -ohjelmaan jossa on vielä paljon vaativammat tietoturvamääräykset.
Ja kun käyttäjä poistaa sovellukseni niin tietokantaa pitäisi, ehkäpä tyhjentää ks. käyttäjän osalta.
Ja tasin myös keksiä jonkinverran Appsia nopeuttavan optimoinnin suorituskyvyssä, joka olisi, että ne issuet joissa ei ole work-logeja niin niiden osalta ei tehtäsi ollenkaan REST-kutsua.
Mut jos sä tallennat sen johonkin muualle, kuin tietokantaan, se on ok?
Eiks datan pääse edelleen lukemaan sieltä, jos haluaa?
Muistiinhan se tallentuu joka tapauksessa käsittelyn ajaksi.
Tietämättä mainittujen sopimusten ehtoja sen tarkemmin, on täysin mahdollista että rajapinnan kautta haettuja tietoja on kielletty tallettamasta ulkopuoliseen järjestelmään pidemmäksi aikaa, kuin tietojen prosessointi käyttäjän pyynnön toteuttamiseksi edellyttää.
Vaikea kuvitella, että sinänsä juuri tietokantaan tallentaminen olisi kiellettyä, mutta esim. muistiin tai tiedostoon tallentaminen olisi sallittua. Eihän siinä olisi mitään järkeä, koska tallennusmedia ei sinänsä ole asian kannalta merkityksellinen. Sen sijaan on olennaista miten pitkäksi aikaa tieto tallennetaan ja millä perusteella sitä säilytetään. Tosin esim. pysyvään muistiin (tiedostoon tai tietokantaan) tallentamisen kieltäminen edes prosessoinnin ajaksi voi olla perusteltua, sillä näihin tieto saattaa jäädä helposti "lojumaan" esim. prosessin virheen tai laitteiston uudelleenkäynnistämisen tms. vuoksi.
Lebe80 kirjoitti:
Mut jos sä tallennat sen johonkin muualle, kuin tietokantaan, se on ok?
Eiks datan pääse edelleen lukemaan sieltä, jos haluaa?
Juu sessioon tallennetun datan voi lukea mutta se tietääkseni tuhoutuu itsestään jossain vaiheessa ja ei jää ikuisesti sessiotiedostoihin.
Tässä tietoturvaehdot:
https://developer.atlassian.com/platform/
Eli idealisesti ei saisi tallentaa mitään asiakkaan dataa omalle palvelimelle mutta kiellettyä se ei ole.
No eiköhän tässä ole olennaisesti jo kerrottu mikä on vikana, keinoja jolla sen voi korjata jne. Eli ei muuta kuin hommiin.
Grez kirjoitti:
No eiköhän tässä ole olennaisesti jo kerrottu mikä on vikana, keinoja jolla sen voi korjata jne. Eli ei muuta kuin hommiin.
Juu nyt kaikki oleellinen on käsitelty ja alan hommiin.
PS: Tämän dokumentaation mukaan worklogit on mahdollista saada issueihin JSON-arrayna, niin ettei niitä tarvitse erikseen hekea erillsellä REST-kutsulla (mutta lienee parasta kysyä Atlassian Developer Communitystä, että miten eikä täältä Ohjelmointiputkasta): https://developer.atlassian.com/cloud/jira/
Tämä topikin voi nyt siis sulkea jos se on tarpeellista.
Tai voisit vaan lukea dokumentaation, sitähän varten se on kirjoitettu...
muuskanuikku kirjoitti:
Tai voisit vaan lukea dokumentaation, sitähän varten se on kirjoitettu...
Niin luin kyllä ja tuossa yllä voi hekea vain 20 ensimmäisstä work-logia joten se ei täytä mun vaatimuksia. Siis arraynä itse issue-arrayn sisään.
Ensinnäkin viesteissäsi on sen verran typoja eli finger failures, että mitä todennäköisimmin niitä löytyy myös koodistasi. Nyt kun en tiedä haetko kerrallaan yhden vaiko useamman asiakkaan dataa niin en pysty suoralta kädeltä antamaan neuvoa. No otetaan lähtökohdaksi yhden asiakkaan datan käsittely kerrallaan: Haet JSON datasta ko. asiakkan noden ja alat pukkaamaan dataa johonkin stringiin aina siihen asti kunnes node päättyy. Pukkaat sitten em. stringin eteen ja perään tarvittavat JSON alku- ja loppupätkät, että voit serialisoida luomasi JSON-stringin.
Silloin kun homma alkaa mennä ylivaikeaksi, niin kannattaa heittää manuaalit roskiin ja tehdä vaikkapa näin: fuck the serialization…
EDIT: Itseäni on PHP aina lähinnä oksettanut, kuten myöskin JAVA.
Niin neosofta:lle vastaus. Googletin tämän keskustelun:
https://community.developer.atlassian.com/t/get-all-the-worklogs-for-the-issues-of-a-jql/48202
Eli ei ole mahdollista tämän keskustelun mukaan muuttaa startAt and maxResult GET-paramenterjä REST-kutsuun: /rest/api/2/search eikä uudempaankaan versioon /rest/api/3/search, joka siis on vasta BETA-versio.
Juu ja kooidssani voi useinkin olla alkuun kirjoiutusvirheitä mm. kommentoinnissa mutta toki korjailen niitä sitä mukaa kun huomaan. Minulla on lukihäiriötä ja sanasokeutta jonkin verran.
Ohjelmistoni on jo ensimmäisen version osalta tuotannossa ja aiheuttaa n. 10 Gt -datasiirron päivässä ja palvelin vaikka siinä on 64 Gt vRAM ja 16-ytiminen vCPU niin silti siellä on alkanut kaatuilla kaikki mahdolliset Java-pohjaiset sovelluksset ja tänään kaatu myös sähköpostipalvelin mutta tietokannat eivät eikä Apache.
Jos käytät POST metodia niin parametrit voi säätää näin.
curl -D- -u <email_address> -H "Content-type: application/json" -d '{"startAt": 10, "maxResults": 20}' -X POST https://<instance>.atlassian.net/rest/api/2/
Jos käytät GET metodia niin parametrit on oltava osana URL -osoitetta:
curl -D- -u <email_address> -H 'Content-type: application/json' -X GET 'https://<instance>.atlassian.net/rest/api/2/
EDIT: Melkein tuli jo oksennus.
neosofta kirjoitti:
(14.09.2021 03:57:09): Jos käytät POST metodia niin parametrit voi...
Niin kyllä minulla on jo issue listauksen ks. muutujat ja käyttöliittymä, jonka olen tehnyt Ext JS 4.2.+:lla generoi uudet startAt ja maxResult-muutujat kun itse Timesheet-sovelluksen loputonta taulukkoa skrollaa alaspäin aina kun 150. rivi ylittyy. Siis se lattaa 50 issueta per sivu ja bufferoi niitä 150 kpl eli 3 kertaa tekee ks. POST/GET REST -kutsun aina uudestaan ja uudestaan sitä mukaa kun talukkoa skrollaa alaspäin. Mutta lisäämällä mm. get-muutujaan fields=*all se tekee myös issuen work-logit omana arraynä mutta vain startAt=0 ja maxResult=20 parameterillä joita ei voi muttaa. Kaikki muu vastava sisältö mikä tulee arrayna itse issueen listaa kaikki mahdoliset sellaiset, kuten kommentit, liitetiedostot, jne.
Kerrassaan oksettava systeemi, onneksi ei tarvitse tämän enempää sekaantua 🤢
neosofta kirjoitti:
Kerrassaan oksettava systeemi, onneksi ei tarvitse tämän enempää sekaantua 🤢
No jos tarkoitat Atlassianin Jira Cloud REST API:a niin siinä on selkeä bugi/puute mikä pakottaa hakemaan work-logit eli ks. softaan käyttäjien syöttämät työnunnit päiväkohaisesti työnaloitus tuntien, minuuttien ja sekuntien aikaleimalla varsutetuna erillisellä REST-kutsulla, joka puolestaan hidastaa koko hommaa.
Jos ketään kiinnostaa niin tässä videot minun Appsin versiosta 1.8.0-AC.
3 pääominaisuuttaa 2 minuutissa: https://www.youtube.com/watch?v=eiSzkZR5lOo
Koko Appsin ominaisudet selitettynä 16 minuutissa: https://www.youtube.com/watch?v=TefD3qnDwVU
Siis nämä videot ovat version 1.8.0-AC beta-versioita ja koitan nyt tehdä ohjelmistotestausta ja etsiä bugeja siitä ja korjata jos mahdollista.
PS: Atlassian on iso Austraalialainen pörssiin listattu ohjelmistotalo ja sen tuotteet omalla alallaan ovat maailman suosituimpia. Muissa vastaavissa sovelluskaupoissa on aina hyvin vaikea menestyö monesta syystä ja tehdä pennin jenniä fyffee. Nimimerkillä olen kokeillut lahes kaikki muut vastavat kuin Atlassian Marketplace ja paljon kukan ei näissä muissa edes hae 30-päivän traialia saatikka osta tuotetta.
walkout_ kirjoitti:
Jos ketään kiinnostaa niin tässä videot minun Appsin versiosta 1.8.0-AC.
Ei millään pahalla herra walkout_, mutta nämä videot on kyllä kovin tuskallisia katsoa. Softa ei näytä mitenkään erikoiselta ja enkun ääntäminen kyllä kruunaa koko homman. Ja osassa videoita on jotain hissimusiikkia taustalla.
Yritin miettiä ihan kohteliaasti että miten näitä voisi parantaa, ehkä ensimmäinen kohde voisi olla enkun ääntämiseen panostaminen.
Tämä on siis ihan briteissä asuvalta palautetta. Jos olet kiinnostunut kansainvälisistä markkinoista niin näillä videoilla ei kyllä ovet vielä aukene.
Mutta kaikkea hyvää ja toivottavasti saat videoiden laatua parannettua ajan kanssa.
jidolom487 kirjoitti:
(17.09.2021 05:39:57): ”– –” Ei millään pahalla herra walkout_, mutta nämä...
Voin ostaa Fivveristä halvalla ammatimasia videoita eikä maksa monta kympiä USA:n taaloissa.
Kysymys lienee että miksi et ole niin tehnyt?
Grez kirjoitti:
Kysymys lienee että miksi et ole niin tehnyt?
Olen Yleisessä edunvalvonnassa ja minulla on edunvavontatilillä n. 12000 € rahaa mutta edunvalvoja on varsinainen natsi eli tiukka rahojen antamisessä yritys tai yksityiskäytöön.
walkout_ kirjoitti:
edunvalvoja on varsinainen natsi eli tiukka rahojen antamisessä yritys tai yksityiskäytöön.
Jotenkin ymmärrän, että varmaan ihan hyvä asia.
Lebe80 kirjoitti:
walkout_ kirjoitti:
edunvalvoja on varsinainen natsi eli tiukka rahojen antamisessä yritys tai yksityiskäytöön.
Jotenkin ymmärrän, että varmaan ihan hyvä asia.
Niin ja mitä se muka auttaa, että tehdään kunnolliset mainokset jopa kalliissa Mainostoimistossa, jossa videoiden teko maksaa tonneja per minuutin video, koska asiakkaat hakee kuitenkinn sen 30-päivän traiajalin ja eivät taatusti osta tuotetta jos se on liian buginen, siinä on liian hämmentävät käyttöliittymä, tms.
Ja eddunvalvonnan takia en pääse tekemään liian kalliita investointeja joista ei ehkä ole mitään hyötyä jolloin toi 12000 € mensi että hujataa.
Sääntö numero 1:
Älä sotke omia ja firman rahoja
Lebe80 kirjoitti:
Sääntö numero 1:
Älä sotke omia ja firman rahoja
Toiminimellä saa sotkea laillisesti mm. omia palkkatuloja ja firman rahoja. Siis hankinnoissa esim.
Ja käsittääkseni OY:llä ei koska sen pitää tuottaa verottajan simissä voitto sen omistjale eikä voi omista rahoista pinentää liikevoitoa.
Vastauksena alkuperäiseen kysymykseen: Tottakai jsonin (tai minkä tahansa) lukeminen rajapinnasta on hitaampaa kuin tiedonhaku samassa verkosta olevasta tietokannasta. Kun haet rajapinnasta tietoa selaimen kautta, kutsu tulee palvelimille ulkoverkon kautta jossa on luonnollisesti suurempi latenssi, mitä backend - tietokanta välisessä yhteydessä.
walkout_ kirjoitti:
Lebe80 kirjoitti:
Sääntö numero 1:
Älä sotke omia ja firman rahoja
Toiminimellä saa sotkea laillisesti mm. omia palkkatuloja ja firman rahoja. Siis hankinnoissa esim.
Saa! Mutta et selvästikään ymmärtänyt lyhyen viestini sisältöä.
walkout_ kirjoitti:
Toiminimellä saa sotkea laillisesti mm. omia palkkatuloja ja firman rahoja. Siis hankinnoissa esim.
Toiminimellä ei ole mitään "firman rahoja". On vain toiminimiyrittäjän rahoja. Ei ole myöskään "firman velkoja", nekin on toiminimiyrittäjän velkoja.
Sitten on sellaiset käsitteet verotuksellisesti kuin elinkeinotoiminnan tulot ja elinkeinotoiminnan menot, joita ei saa sotkea henkilökohtaisiin tuloihin ja menoihin.
Verotuksellisesti on siis tärkeää pitää firman tulot ja menot erillään henkilökohtaisista tuloista ja menoista. Tätä kutsutaan kirjanpidoksi. Toiminimiyrittäjälle on sallittu yhdenkertainen kirjanpito, mutta myös kahdenkertaisen kirjanpidon pitäminen on sallittua. Rahojen pitäminen erillään ei sinänsä ole tarpeen, kunhan vaan ymmärtää pitää tilillä (tai patjan alla) riittävästi rahaa, että pystyy huolehtimaan sekä omista että "firman" velvoitteista.
En tiedä pitikö tuo leben vinkki ymmärtää niin, että mitään isompaa toimintaa ei kannata harjoittaa toiminimellä vaan esim. perustaa Oy, jolloin firman rahat ja omat rahat ovat ihan oikeasti erikseen. Vinkki on ihan hyvä, tarkoittipa Lebe sitä tai ei. Ilmeisesti holhouksenalainen ei kuitenkaan voi perustaa osakeyhtiötä, vaikka edunvalvojalta tarvittava 275 euroa irtoaisikin.
Grez kirjoitti:
(21.09.2021 15:41:29): ”– –” Toiminimellä ei ole mitään "firman rahoja". On...
Juu. Oy:n voin kyllä perustaa mutta se on heikkoa, koska en saa olla hallituksen jäsen tai puhumattakaan Pj, koska olen holhouksessa ja kuka nyt tulisi minun vähäisllä liikevaihdoilla ks. pesteihin ilmaiseksi ja vain minä nostaisin firmasta palkkaa?
Sinänsä jos saisit Oy:n avulla (paremmalla markkinoinnilla jne) kasvatettua liikevaihdon ja voiton vaikka 4 -kertaiseksi, niin siitä kannattaisi kyllä jakaa vaikka kolmasosa jollekin ammattihallitusihmiselle. Eli isosta kakusta viipalekin voi olla isompi kuin pieni kakku kokonaan.
Toki tuo on iso JOS.
Jos saisi liikevaihdon kasvatettua vaikka 20. -kertaiseksi, niin siitä kannattaisi kyllä jakaa vaikka puolikas omiin boonuksiin.
Huomioitavaa on, että jos teettää mainosvideon oikeassa mainostoimistossa niin sellainen maksaa tuhansia per 1 minuutti. Ne ovat yleensä hinnoitelut videon keston mukaan. Esim. Selitysvideosta tilattuna lähtöhinta on jo AVL:n kanssa n. 1000 €. Johon mulla olisi kyllä varaa kerran vuodessa nykyisellä liikevaihdolla. Tämä siksi, että käytin 10-vuoden liikevaihdosta varmaankin 20000 € DJ-laitteden, Showlasereiden ja Musiikkistudiolaitteiden hankintaan. Mutta tämä oli ehkä vähän hölmöä, koska musiikin julkaisulla mm. Beatportiin, Juno Downloadiin, Spotifyyn, jne. on melkovaikeaa saada kunnollisia tuloja, koska esim. yhden mp3:n myynistä saa n. 40 senttiä ja tarvitaan 10000 Spotify-soittoa että saa n. 50 €. Nyt kuitenkin levy-yhtiölläni Spin Underground Records:lla on rahoitus Intian Dubaista, Seedj nimisen plavelun osalta, josta musiikintekijät maksavat hyvin kallista kk-maksua ja Seedj taas puolestaan maksaa meille XX € kertakorvauksen jokaisesta musiikiraidasta, jotka ovat julkaistu Seedj:n kautta. Esim. julkaisemalla kukaudessa niin montoa 10-20 raidan pitkäsoittolyvä kuin mahdollista niin tienaa jo jopa muutaman tuhat € / kk.
Jos et keikkaa tee niin showlasereiden hankintaa ei ainakaan striimipalveluiden kautta voi perustella. En ainakaan keksi mitä hyötyä valokamoista on spotifyn sisällöntuottoon.
Sehän on yksi asia mitä oikeasti kannattaa hankkia ja toinen asia mitä leluja olis kiva olla.
groovyb kirjoitti:
Jos et keikkaa tee niin showlasereiden hankintaa ei ainakaan striimipalveluiden kautta voi perustella. En ainakaan keksi mitä hyötyä valokamoista on spotifyn sisällöntuottoon.
Kenties holhoaja nimitettiin juurikin ylläolevasta syystä
carabia kirjoitti:
groovyb kirjoitti:
Jos et keikkaa tee niin showlasereiden hankintaa ei ainakaan striimipalveluiden kautta voi perustella. En ainakaan keksi mitä hyötyä valokamoista on spotifyn sisällöntuottoon.
Kenties holhoaja nimitettiin juurikin ylläolevasta syystä
Keikka tein mutta niistä ei maksettu penniäkään luukuun ottamtta paria keikkaa. Siis DJ-keikkaa vaan.
Holhoja on nimetty pitkän pikavippikierteen takia, joka 2013 karkasi vähän lapasesta. Ja minulla oli opintolainaa 6500 € näiden lisäksi ja osamaksukauppoja. Yhteensä kaikkilainet mukaan lukien niitä oli joku 18000 € korkoineen.
Nyt kuintenkin velat ovat maksettu kaikki kertamaksulla pois iso-vanhempien perinnöstä jääneen nettovarallisuuden saldosta ja minulle jä tämän jälkeen n. 12000 € rahaa joka on edelleen edunvalvontatilillä. Olen siis nyt olut jo täsin velaton kokonaisen vuoden.
Älä nyt tuhlaa niitä.
Lebe80 kirjoitti:
Älä nyt tuhlaa niitä.
En ajatellutkaan, koska jos jotain käy ja huonosti, esim. asikkamme ei uusikkaan tämän kuun lopussa Atlassian Marketplacessa myynnissä olevan tuotteen lisenssiä 10000 käyttäjlle niin palvelimeni maksaa kuihenkin 3-vuoden kertamaksusopimuksella n. 1500 € ja koska olen pistänyt nimen Atlassian Marketplace -sopimukseen ja julkaissut sekä omalle palvelimelle asennettavan että pilviversion sinne niin Atlassianin sopparistapas ei helposti eroon päästä ja palvelin on pidettävä keinolla millä hyvänsä ikusesti ylläpidossa 99.99 % up-timellä jos vain mahdollista. Jos muutan palvelimen vain kk-maksulliseksi niin sen hinta nousee kk-hinnaltaan jonkin %-yksikön ja alkaa maksaa n. 50 € / kk ja tämän pystyn kyllä maksamaan sairaseläkevaroistani.
Mutta Yleinen edunvalvoja, joka minulle on määrätty ei ymmärrä tätä kokonaisuutta ja voi kieltäytyä antamasta rahaa maksaa seuraavan palvelin laskun ja hän ei edes osaa lukea veroiloituksiani, että miten paljon olen tienannut per vuosi ja joutuu soitteleen minun kirjanpitäjälle saadakseen tarkemmat tiedot asiasta. Totuus on kuitenkin se, että tulorajani on tiukka 10000 € / vuosi ja viime vuonna liikevaihtoni oli melkein 20000 € ja käytin siitä aika paljolti verovähennys kelpoisiin hankintoihin, että sain pudottetua oman palkkani alle 10000 €. Samoin maksoin kaikki verot ja YEL-vakuuteksen ajallaan.
Nyt haen hädissään töitä, siis palkkatöitä ja kaikkea muuta asiaan liittyvä, että saisin talouden kuntoon, koska tänävuonna minulla ei ole valitettavasti merkittävää rahaa tekevää toimeksiantajaa.
Aihe on jo aika vanha, joten et voi enää vastata siihen.