De Devschuur Coffee Corner - Iteratie 6

[vpm]

Voor (complexe) validatie kan ik begrijpen dat dat makkelijk af te vangen is dmv soap dan json.

Grijze Vos schreef op donderdag 31 juli 2014 @ 14:14:
[...]
Als je heel simpele one-request-one-response achtige dingen bouwt is Soap zwaar overkill.

Echter is dit veelal het geval...

Weet niet hoe dat bij overheidsinstanties/big business gaat en dat het daar wel nodig is.

---

Waar blijft Iteratie 7?!

[ Voor 3% gewijzigd door vpm op 31-07-2014 14:17 ]

[Caelorum]

vpm schreef op donderdag 31 juli 2014 @ 14:16:
[...]

---

Waar blijft Iteratie 7?!

Nog iets van 1000 posts te gaan in dit topic toch?

[vpm]

Flink spammen dan

[Firesphere]

Gamebuster schreef op donderdag 31 juli 2014 @ 13:52:
Vraagt een partij wat m'n voorkeuren zijn voor een API. Ik zeg: Doe lekker simpel HTTP calls met JSON responses.

Paar weken later: "Hier is onze SOAP koppeling. Wat vind je ervan?"

Vraag het dan niet ofzo... Ik haat SOAP.

Een goed opgezette SOAP koppeling is helemaal niet ingewikkeld. Het wordt vervelend als de bouwer z'n eigen interpretatie er van gaat maken.

[Erwin537]

Caelorum schreef op donderdag 31 juli 2014 @ 12:57:
[...]

K800 en een Performance MX En jeeh voor unifying receivers. Enige jammere vind ik is dat je niet aan twee van die dingen kan koppelen. Dus kan mijn tobo niet makkelijk aan mijn laptop hangen. Niet dat ik dat vaak wil doen, maar toch, beetje jammer die beperking. Aan de andere kant wel maar 1 usb poort in bezet voor zowel mijn tobo als muis. Da's dan wel weer handig.

Je bedoelt 1 tobo aan 2 unifying adapters?

Het is wel mogelijk om twee losse apparaten aan één unifying adapter te koppelen toch? Ik zie namelijk niet echt een voor mij goede combi van tobo en muis, dus wil los een muis (waarschijnlijk performance mx) en tobo aanschaffen.

[Laurens-R]

In een Enterprise omgeving is SOAP voor berichten verkeer een minimale vereiste. Het lijkt wellicht overkill, maar als het bijv. om grote bedragen gaat wil je elke vorm van validatie hebben die je kan krijgen, omdat het letterlijk miljoenen euro's kan kosten.

[Geo001]

waarom zou je met 1 tobo/muis 2 pc's willen bedienen? ga je synchroom KaM-men? (Of red alert, aoe, settlers..)

[Erwin537]

Geo001 schreef op donderdag 31 juli 2014 @ 14:28:
waarom zou je met 1 tobo/muis 2 pc's willen bedienen? ga je synchroom KaM-men? (Of red alert, aoe, settlers..)

Als je een desktop en laptop hebt, en je tobo meeneemt met je laptop zou dat heel handig kunnen zijn, dan hoef je die adapter niet over te zetten.

[Tjolk]

Ryur schreef op donderdag 31 juli 2014 @ 14:08:
[...]

Waarom "wij" SOAP gebruiken:
Door SOAP kan je makkelijk allerlei validaties doen op de payload (XML).
Omdat "wij" ERP-systemen bouwen, moeten wij allerlei validaties afvangen, en hierdoor hebben wij hele uitgebreide XSD's.

Voordeel is dus dat de response dat richting onze ERP-pakketten gaat als gecontroleerd wordt (op validiteit) voordat het door de interne validaties gaat.

Voor de meeste situaties vind ikzelf SOAP ook te log, maar er zijn wel gevallen dat 'maar' JSON niet voldoende is.

Dit. De WSDL vangt al heel veel af; als het niet aan de WSDL voldoet wordt de rest simpelweg niet uitgevoerd. Scheelt een hoop.

[Geo001]

Erwin537 schreef op donderdag 31 juli 2014 @ 14:34:
[...]

Als je een desktop en laptop hebt, en je tobo meeneemt met je laptop zou dat heel handig kunnen zijn, dan hoef je die adapter niet over te zetten.

Ja dat was dus niet meteen duidelijk! ik zag al 2 pc's naast tegelijk aan

[Laurens-R]

Een oplossing die goed voor mij werkt: http://synergy-project.org/

keyboard/mouse switch over TCP/IP. Zorg alleen dat als je games speelt, dat je je keyboard/muis aansluit op de game pc... anders heb je last van network latency tijdens het gamen.

[_Moe_]

Erwin537 schreef op donderdag 31 juli 2014 @ 14:34:
[...]

Als je een desktop en laptop hebt, en je tobo meeneemt met je laptop zou dat heel handig kunnen zijn, dan hoef je die adapter niet over te zetten.

Sleur jij je tobo altijd met je laptop mee?

[Caelorum]

Erwin537 schreef op donderdag 31 juli 2014 @ 14:34:
[...]

Als je een desktop en laptop hebt, en je tobo meeneemt met je laptop zou dat heel handig kunnen zijn, dan hoef je die adapter niet over te zetten.

Dat dus. Mijn laptop staat praktisch nooit tegelijkertijd met mijn desktop aan. Ik had dan ook graag gezien dat die verbinding zou maken met 1 ontvanger en als die niet online is met een andere. Dat doet die echter niet. Hij onthoud maar 1 ontvanger, waar die mee is gekoppeld. Ik snap dat eigenlijk ook niet, want eerdere versies van dit product onthielden wel elke ontvanger die je kon koppelen. Als je die telkens koppelde en dan ("verkeerd") ontkoppelde kon je de muis terugsturen naar logitech omdat die gebrickt was en niet meer wilde koppelen. Dat heb ik onder meer gehad
Dus de muis kan duidelijk meer in de firmware dan nu wordt gebruikt.

[Creepy]

Firesphere schreef op donderdag 31 juli 2014 @ 14:26:
[...]

Een goed opgezette SOAP koppeling is helemaal niet ingewikkeld. Het wordt vervelend als de bouwer z'n eigen interpretatie er van gaat maken.

Of de client zijn eigen implementatie maakt. Ik heb nu al meerdere keren devvers gezien die zelf hun eigen XML aan het samenstellen waren om requests te kunnen maken. De WSDL importeren en code laten genereren was simpelweg niet in ze opgekomen. Maar dan dus wel om support komen vragen omdat het niet werkt en of ze een voorbeeld XML kunnen krijgen.. *zucht*

[wackmaniac]

Of dat er om een SOAP-koppeling wordt gevraagd en de ontvangende partij vervolgens een volstrekt verouderde library gebruikt en jouw de schuld geeft dat het niet werkt ...

[Erwin537]

_Moe_ schreef op donderdag 31 juli 2014 @ 14:37:
[...]


Sleur jij je tobo altijd met je laptop mee?

Ik heb inderdaad een toetsenbord dat ik meeneem. Nu nog zo'n ouderwetse dell die ik noghal liggen, maar die is toch wat bulky.

De reden dat ik een tobo meeneem is dat wij allemaal flex werkplekken hebben en dus gewoon een laptop krijgt en aan een leeg bureau kan gaan zitten. Om te voorkomen dat ik constant met een verkeerde houding voorovergebogen voor m'n laptop zit heb ik een laptop standaard gekregen. Maar op die laptop kan je niet meer typen, vandaar dat ik een apart toetsenbord nodig heb.

[_Moe_]

Erwin537 schreef op donderdag 31 juli 2014 @ 14:43:
[...]

Ik heb inderdaad een toetsenbord dat ik meeneem. Nu nog zo'n ouderwetse dell die ik noghal liggen, maar die is toch wat bulky.

De reden dat ik een tobo meeneem is dat wij allemaal flex werkplekken hebben en dus gewoon een laptop krijgt en aan een leeg bureau kan gaan zitten. Om te voorkomen dat ik constant met een verkeerde houding voorovergebogen voor m'n laptop zit heb ik een laptop standaard gekregen. Maar op die laptop kan je niet meer typen, vandaar dat ik een apart toetsenbord nodig heb.

Kunnen ze dan niet gewoon netjes op elke flex werkplek een laptopstand met toetsenbord en muis voorzien? Dat deden ze op mijn vorig werk en daar waren nauwelijks problemen bij.

[wackmaniac]

Zie hier op kantoor al verschillende voorkeuren voor toetsenborden, dus dan kan je de mensen net zo makkelijk zelf een laten aanschaffen en dit vergoeden.

[Erwin537]

_Moe_ schreef op donderdag 31 juli 2014 @ 14:45:
[...]


Kunnen ze dan niet gewoon netjes op elke flex werkplek een laptopstand met toetsenbord en muis voorzien? Dat deden ze op mijn vorig werk en daar waren nauwelijks problemen bij.

Ik heb een budget gekregen om zelf hardware aan te schaffen en de laptopstand is opvouwbaar

[_Moe_]

Lijkt me alleen verschrikkelijk om dat telkens geheel mee te sleuren. Dan zou het nog makkelijker zijn om elke bureau van een thin client pc te voorzien en vervolgens iedereen een persoonlijk toetsenbord te geven. Moet je enkel je tobo nog meesleuren.

Erwin537 schreef op donderdag 31 juli 2014 @ 14:53:
[...]

Ik heb een budget gekregen om zelf hardware aan te schaffen en de laptopstand is opvouwbaar

Dus die moet je ook nog meesleuren

[Firesphere]

Creepy schreef op donderdag 31 juli 2014 @ 14:40:
[...]

Of de client zijn eigen implementatie maakt. Ik heb nu al meerdere keren devvers gezien die zelf hun eigen XML aan het samenstellen waren om requests te kunnen maken. De WSDL importeren en code laten genereren was simpelweg niet in ze opgekomen. Maar dan dus wel om support komen vragen omdat het niet werkt en of ze een voorbeeld XML kunnen krijgen.. *zucht*

Dit doe ik alleen als de WSDL dus foutief is Anders gewoon lekker laten genereren door je engine inderdaad.

[Dido]

Firesphere schreef op donderdag 31 juli 2014 @ 14:54:
Dit doe ik alleen als de WSDL dus foutief is Anders gewoon lekker laten genereren door je engine inderdaad.

Moet je wel een engine hebben

Jarenlang op een platform gewerkt waar dat genereren dus gewoon niet kon.

Had wel tot gevolg dat ik er vrij goed in werd om zelf aan de hand van een wsdl code te schrijven, maar 9 van de 10 keer bleek de wsdl niet te kloppen.
Hij was out-of-date, of, en dat kwam vaker voor, alles was gedefinieerd als string. Handig voor een timestamp. En als je dan vraagt wat voor formaat timestamp het moet zijn, als antwoord krijgen "maakt niet uit". Terwijl hun service toch echt geen antwoord gaf met gangbare formaten

Of, de ergste: Een SOAP message met 1 parameter: <PARAMETER>.
En wat moet daar dan in? Nou, een string met (escaped) xml natuurlijk. logisch toch.
En is daar ergens op zijn minst een xsd van? Nou, eh, nee. Maar ik heb hier wel een voorbeeld-xml.

[Firesphere]

Dido schreef op donderdag 31 juli 2014 @ 14:59:
[...]

Moet je wel een engine hebben

Jarenlang op een platform gewerkt waar dat genereren dus gewoon niet kon.

Had wel tot gevolg dat ik er vrij goed in werd om zelf aan de hand van een wsdl code te schrijven, maar 9 van de 10 keer bleek de wsdl niet te kloppen.
Hij was out-of-date, of, en dat kwam vaker voor, alles was gedefinieerd als string. Handig voor een timestamp. En als je dan vraagt wat voor formaat timestamp het moet zijn, als antwoord krijgen "maakt niet uit". Terwijl hun service toch echt geen antwoord gaf met gangbare formaten

Of, de ergste: Een SOAP message met 1 parameter: <PARAMETER>.
En wat moet daar dan in? Nou, een string met (escaped) xml natuurlijk. logisch toch.
En is daar ergens op zijn minst een xsd van? Nou, eh, nee. Maar ik heb hier wel een voorbeeld-xml.

En in die XML die in <PARAMETER> zat, zat zeker een verwijzing naar een zip-bestand wat je kan downloaden waar de uiteindelijke XML in stond.

[StM]

Wees blij dat het nog geescapede xml was * StM mompelt iets over een koppeling waar dit niet zo was waardoor eigenlijk geen fatsoenlijke xml parser er mee overweg kon. Lang leve wat regex om die embedded xml er maar uit te strippen

[Dido]

Firesphere schreef op donderdag 31 juli 2014 @ 15:04:
En in die XML die in <PARAMETER> zat, zat zeker een verwijzing naar een zip-bestand wat je kan downloaden waar de uiteindelijke XML in stond.

Iets dergelijks is inderdada wel eens voorgekomen

StM schreef op donderdag 31 juli 2014 @ 15:05:
Wees blij dat het nog geescapede xml was * StM mompelt iets over een koppeling waar dit niet zo was waardoor eigenlijk geen fatsoenlijke xml parser er mee overweg kon. Lang leve wat regex om die embedded xml er maar uit te strippen

"escaped" was een best-case beschrijving, helaas

D'r zijn eigenlijk best wel wat dingen die ik heel erg niet mis aan dat ontwikkelplatform

[.Gertjan.]

Argh, f*cking Facebook! Kreeg een melding van een klant dat op een bepaalde omgeving een van de integraties met FB om was gekukeld. Prima gaan we even kijken of we kunnen reproduceren. Na veel klooien eindelijk de bug kunnen reproduceren, leek te liggen aan de gebruikte App tokens. Alles behalve 1 app werkte ...

Na wat klooien bleek dat we een deprecated call gebruikte (search posts). Nieuwe apps gebruiken standaard de laatste API dus dan maar handmatig naar 1.0 zetten. No way dus, apps die geregistreerd zijn na 30 april mogen de oude api's niet gebruiken. En de pest is dat we per eindklant een nieuwe app moeten registreren (omdat ze op aparte domeinen draaien)... Facebook heeft dus per 30 april een van de features van onze applicatie de nek omgedraaid...

En bedankt he! Nu moet ik dus mijn klanten gaan vertellen: "ja joh, weet je, die functie van x euro, tja die is kapot en gaat nooit meer werken"...

[Swedish Clown]

Recentelijk een nieuwe laptop ontvangen van m'n werkgever. Een Dell Latitude E7440-1862, de laptop wordt echter rustig 80 graden tijdens full load 3.2 GHz. Heb nu maar een provisorische laptop standaard geknutseld om de laptop iets meer lucht te geven maar blijf het erg warm vinden voor een laptop.

[Cartman!]

.Gertjan. schreef op donderdag 31 juli 2014 @ 15:14:
En bedankt he! Nu moet ik dus mijn klanten gaan vertellen: "ja joh, weet je, die functie van x euro, tja die is kapot en gaat nooit meer werken"...

Lijkt me de minst erge manier van vertellen, je kan met je vinger naar facebook wijzen en die functie van x euro heb je al in je zak zitten. Wij hebben nog honderden apps uit 1.0 dus zolang een app niet tot volgend jaar april live hoeft te blijven kunnen we die recyclen

[Firesphere]

.Gertjan. schreef op donderdag 31 juli 2014 @ 15:14:
Argh, f*cking Facebook! Kreeg een melding van een klant dat op een bepaalde omgeving een van de integraties met FB om was gekukeld. Prima gaan we even kijken of we kunnen reproduceren. Na veel klooien eindelijk de bug kunnen reproduceren, leek te liggen aan de gebruikte App tokens. Alles behalve 1 app werkte ...

Na wat klooien bleek dat we een deprecated call gebruikte (search posts). Nieuwe apps gebruiken standaard de laatste API dus dan maar handmatig naar 1.0 zetten. No way dus, apps die geregistreerd zijn na 30 april mogen de oude api's niet gebruiken. En de pest is dat we per eindklant een nieuwe app moeten registreren (omdat ze op aparte domeinen draaien)... Facebook heeft dus per 30 april een van de features van onze applicatie de nek omgedraaid...

En bedankt he! Nu moet ik dus mijn klanten gaan vertellen: "ja joh, weet je, die functie van x euro, tja die is kapot en gaat nooit meer werken"...

Tja, jammer joh. Facebook heeft z'n API aangepast. Dus dat gaat niet meer werken. Kan ik niks aan doen, ik heb opgeleverd. Doei, veel plezier, als je me geld geeft zoek ik een nieuwe oplossing voor je.

[OkkE]

Hadden wij een tijd geleden ook met Twitter, toen die zijn API had gewijzigd. Klanten vertelt dat het niet aan ons lag en dat we het tegen betaling konden fixen. Eigenlijk niet een klant deed er echt moeilijk over.

[Blubber]

.Gertjan. schreef op donderdag 31 juli 2014 @ 15:14:
Argh, f*cking Facebook! Kreeg een melding van een klant dat op een bepaalde omgeving een van de integraties met FB om was gekukeld. Prima gaan we even kijken of we kunnen reproduceren. Na veel klooien eindelijk de bug kunnen reproduceren, leek te liggen aan de gebruikte App tokens. Alles behalve 1 app werkte ...

Na wat klooien bleek dat we een deprecated call gebruikte (search posts). Nieuwe apps gebruiken standaard de laatste API dus dan maar handmatig naar 1.0 zetten. No way dus, apps die geregistreerd zijn na 30 april mogen de oude api's niet gebruiken. En de pest is dat we per eindklant een nieuwe app moeten registreren (omdat ze op aparte domeinen draaien)... Facebook heeft dus per 30 april een van de features van onze applicatie de nek omgedraaid...

En bedankt he! Nu moet ik dus mijn klanten gaan vertellen: "ja joh, weet je, die functie van x euro, tja die is kapot en gaat nooit meer werken"...

Dat is klote ja, maar ik vind dat niet de schuld van Facebook. Als je zo'n feature verkoopt die afhankelijk is van een externe API dan moet je ook op de hoogte blijven van aanpassingen aan die API.

P.S.: Leuke dag voor jou, eerst met je VB problemen en nu dit, succes .

[Tjolk]

Gevalletje overmacht inderdaad. Jij bent afhankelijk van Facebook om een Facebook app te laten werken. Als Facebook dan dingen gaat wijzigen na oplevering van jouw werk, dan kun jij daar niet voor verantwoordelijk worden gehouden.

Tenzij Facebook dat destijds al had aangekondigd natuurlijk.

[wackmaniac]

Ligt beetje aan het contract dat je hebt; was het eenmalig bouwen en wegwezen of heeft de klant ook iets van een onderhoudscontract. In dat laatste geval is het logisch dat de klant verwacht dat jij het kostenloos oplost. Hebben hier hetzelfde gehad met de Twitter-API die veranderd werd. Hebben we allemaal voor eigen kosten moeten doen. Wel een mailing naar alle klanten dat we dat gingen doen; wilden er zomaar een hele berg klanten ook een koppeling met Twitter

[.Gertjan.]

Ger schreef op donderdag 31 juli 2014 @ 15:29:
Gevalletje overmacht inderdaad. Jij bent afhankelijk van Facebook om een Facebook app te laten werken. Als Facebook dan dingen gaat wijzigen na oplevering van jouw werk, dan kun jij daar niet voor verantwoordelijk worden gehouden.

Tenzij Facebook dat destijds al had aangekondigd natuurlijk.

Facebook heeft de feature begin dit jaar deprecated gemaakt, zonder enkele reden. Ik heb geen flauw idee waarom ze niet meer willen dat je in posts kunt zoeken. Toen stond onze feature al productie klaar. Helaas is FB redelijk aan het zagen in de API, want ook bepaalde post acties mag je niet zomaar doen vanuit een app. zeker niet als je het indirect doet (dus via de server ipv de user door te persen naar een facebook popup).

Aangezien dit een implementatie is in een backoffice systeem kan ik niet zomaar een popupje tonen van Facebook, daarnaast wil je juist dat mensen niet hun persoonlijk FB account hoeven te koppelen maar dat het systeem een vast account gebruikt.

Facebook lijkt enkel te denken aan mobiele gebruikers of integraties op websites en niet aan mensen die Facebook gebruiken voor monitoring of analyses.

Blubber schreef op donderdag 31 juli 2014 @ 15:29:
[...]
Dat is klote ja, maar ik vind dat niet de schuld van Facebook. Als je zo'n feature verkoopt die afhankelijk is van een externe API dan moet je ook op de hoogte blijven van aanpassingen aan die API.

Eens, maar de grote snelheid waarmee Facebook (maar ook Twitter) hun API's weet te deprecaten is redelijk bizar. Ik werk ook aan software voor bedrijven die niet iedere maand een update willen draaien. Als ik op een API vertrouw verwacht ik niet dat ze binnen korte termijn iets deprecaten en vervolgens de stekker eruit trekken. Ik weet dat je een API moet blijven monitoren, maar dit gaat mij echt wel iets te snel, daarnaast lukt het ze om bij iedere update aan de API andere zaken te slopen of bijvoorbeeld weer verplicht te stellen dat je de API versie meegeeft (en dat moet je dan per direct fixen). Voor een bedrijf met een publieke API vind ik dat ze behoorlijk lomp bezig zijn.

Ik ben niet de enige die de zoek functie van FB gebruikt, er zijn zelfs bedrijven die geld verdienen aan het analyseren van trends op social media. Dit soort acties is wat mij betreft een hele grote middelvinger richting die consumerende partijen.

Dat ik nu met een niet werkend pakket zit is niet het probleem van Facebook en vast niet hun schuld, maar voor zo'n "gevestigde" naam vind ik het wel een beetje een bijzonder hoe ze met hun api's omgaan. Want als apps/games/whatever niet meer werken met Facebook is dat ook negatief voor het beeld van FB.

P.S.: Leuke dag voor jou, eerst met je VB problemen en nu dit, succes .

Leuk is anders ja

[Sgreehder]

Firesphere schreef op donderdag 31 juli 2014 @ 15:20:
[...]

Tja, jammer joh. Facebook heeft z'n API aangepast. Dus dat gaat niet meer werken. Kan ik niks aan doen, ik heb opgeleverd. Doei, veel plezier, als je me geld geeft zoek ik een nieuwe oplossing voor je.

Wauw, je zal er wel een tegenkomen die een redelijke advocaat in dienst heeft met zo'n houding.

[Douweegbertje]

Sgreehder schreef op donderdag 31 juli 2014 @ 15:49:
[...]


Wauw, je zal er wel een tegenkomen die een redelijke advocaat in dienst heeft met zo'n houding.

Je zult maar niet begrijpen dat wat hier gepost is niet letterlijk naar de klant gaat. Sowieso, tis maar net hoe je het hebt afgevangen in het contract c.q. voorwaarden. Als het kapot gaat vanwege een 3e partij dan hoef je hier niet direct verantwoordelijk voor zijn. Vooral niet als het een feature is waar de klant om gevraagd heeft ipv een core functionaliteit..
Vrij normaal dus dat de klant mag betalen voor een eventuele update.

Oh en leuk voor die advocaat, maar die heeft ook geen poot om op te staan tenzij ergens staat aangegeven dat je 100% verantwoordelijk bent en garandeert dat de 'app' blijft werken. Iets wat gewoon niet voorkomt tenzij je of: dom bent of b; veeel betaald krijgt p/m of in eerste instantie.


Sowieso kan ik niet tegen zinnetjes met het woordje advocaat erin, hoor zoveel mensen die dat roepen terwijl iemand met fatsoenlijk verstand weet dat het amper gebeurt. Ik heb ongeveer 100 mails gehad waarbij zulke 'dreigementen' naar voren kwamen (betreft domeinnamen dan) terwijl ik nog nooit iets op papier heb gezien.
Elke normale advocaat lacht je uit als je met zo'n opzet naar hem toe komt, aangezien hij wel beter weet.

[.Gertjan.]

Douweegbertje schreef op donderdag 31 juli 2014 @ 15:59:
Sowieso kan ik niet tegen zinnetjes met het woordje advocaat erin, hoor zoveel mensen die dat roepen terwijl iemand met fatsoenlijk verstand weet dat het amper gebeurt. Ik heb ongeveer 100 mails gehad waarbij zulke 'dreigementen' naar voren kwamen (betreft domeinnamen dan) terwijl ik nog nooit iets op papier heb gezien.

Wat zeg jij daar? Belachelijk! Ik ga meteen mijn advocaat bellen!

Ik denk ook niet dat men er heel lastig over gaat doen, is ook een stukje ondernemersrisico, maar ik voel mij er zelf ook niet helemaal goed bij. Ik ben nu bijvoorbeeld een halve dag bezig geweest om de boel uit te zoeken, want de fout lag niet direct voor de hand. Zelf zit ik dan te twijfelen of ik zelf ook niet wat verlies moet nemen. Hoewel de functie klaar was is hij nooit bij een eindgebruiker terecht gekomen (lange trajecten), zelf vind ik het dan ook niet helemaal fair om alles bij de klant te leggen. Ik behoud mijn klanten graag en zie graag dat ze de facturen betalen omdat ze vinden dat er ook correct werk is geleverd. Paar euro verlies nemen ten gunste van omzet in de toekomst is geen probleem wat dat betreft

Er zijn ook wel wat klanten geweest die proberen een factuur te betwisten of probeerde een deel van de uitloop op mij te schuiven. Dat vind ik wat minder tof, maar als iets gewoon niet werkt/kan of gewoon teveel tijd heeft gekost dan ben ik niet te beroerd om zelf ook een stuk op mij te nemen Want ik ben ook ondernemer en heb dus ook risico

Helaas zien klanten dit soms als handreiking om nog verder af te pingelen, dat zijn dan na verloop van tijd geen klanten meer

[alienfruit]

Facebook API is echt een hel om mee te werken...

[ Voor 4% gewijzigd door alienfruit op 31-07-2014 16:17 ]

[Firesphere]

Sgreehder schreef op donderdag 31 juli 2014 @ 15:49:
[...]


Wauw, je zal er wel een tegenkomen die een redelijke advocaat in dienst heeft met zo'n houding.

Die advocaat zal daar niets tegen kunnen doen. Zoiets heet garantie. En in de garantie neem ik nooit functionaliteit van een derde partij op. Ik mag hopen dat niemand dat doet.

Dus als een third-party de boel wijzigt, waardoor mijn applicatie niet meer werkt, dan ben ik echt niet verplicht om daar iets aan te doen. Daar mag de klant voor gaan betalen, of het er bij laten als de gewenste functionaliteit niet meer beschikbaar is.

In other words: Doei, jammer joh, niks aan te doen.

alienfruit schreef op donderdag 31 juli 2014 @ 16:17:
Facebook API is echt een hel om mee te werken...

Valt wel mee, je moet alleen weten hoe je er mee om moet gaan.

[ Voor 14% gewijzigd door Firesphere op 31-07-2014 16:19 ]

[.Gertjan.]

alienfruit schreef op donderdag 31 juli 2014 @ 16:17:
Facebook API is echt een hel om mee te werken...

Gelukkig zijn een aantal testers/project managers het daar mee eens. Die zagen dit als mooie mogelijkheid om de Facebook integratie er eens voorzichtig wat uit te slopen

Zat ook eens te kijken naar de Public Feed of andere API's, maar die zijn helaas alleen maar toegankelijk voor vertrouwde partners. Staan leuke grote namen tussen, een aantal verkopen die data weer. Met andere woorden, Facebook gaat hier gewoon een prijskaartje op plakken...

Andere clubs zijn weer geen fan van API's, die hebben liever dat je hun suite gebruikt... Al met al, nogal ruk...

[Tjolk]

Firesphere schreef op donderdag 31 juli 2014 @ 16:19:
[...]

Die advocaat zal daar niets tegen kunnen doen. Zoiets heet garantie. En in de garantie neem ik nooit functionaliteit van een derde partij op. Ik mag hopen dat niemand dat doet.

Dus als een third-party de boel wijzigt, waardoor mijn applicatie niet meer werkt, dan ben ik echt niet verplicht om daar iets aan te doen. Daar mag de klant voor gaan betalen, of het er bij laten als de gewenste functionaliteit niet meer beschikbaar is.

In other words: Doei, jammer joh, niks aan te doen.

Inderdaad. Zie het zo:

Klant koopt bij dealer een mooie wagen om op circuit mee te rijden. Dealer geeft advies voor goede wagen voor dat circuit. Klant krijgt wagen afgeleverd, circuit wordt gesloten.
Dan heeft die klant gewoon pech en de dealer valt niets aan te rekenen. Hooguit dat je wat coulance kunt krijgen bij inruil.

[kwaakvaak_v2]

Firesphere schreef op donderdag 31 juli 2014 @ 15:20:
[...]

Tja, jammer joh. Facebook heeft z'n API aangepast. Dus dat gaat niet meer werken. Kan ik niks aan doen, ik heb opgeleverd. Doei, veel plezier, als je me geld geeft zoek ik een nieuwe oplossing voor je.

psies... dat dus... ik geef bij FB apps altijd aan dat het werkt totdat FB de API omgooit. Gelukkig doen ze dat niet zo heel erg vaak, en probeer ik meestal wel gebruik te maken van de meest recente.

Je kunt niet eeuwig garantie blijven geven op een een webapp in mijn optiek.

Als je daarentegen de app 2 maanden terug hebt opgeleverd ben je zelf gewoon stom geweest, FB heeft ik meen ergens eind vorig jaar al verteld dat de nieuwe API afgedwongen zou worden rond deze tijd.

[HuHu]

Ger schreef op donderdag 31 juli 2014 @ 16:22:
[...]

Inderdaad. Zie het zo:

Klant koopt bij dealer een mooie wagen om op circuit mee te rijden. Dealer geeft advies voor goede wagen voor dat circuit. Klant krijgt wagen afgeleverd, circuit wordt gesloten.
Dan heeft die klant gewoon pech en de dealer valt niets aan te rekenen. Hooguit dat je wat coulance kunt krijgen bij inruil.

Het zou een dealer sieren als hij erbij vermeld dat het circuit wordt gesloten. Je kunt hem niets aanrekenen, maar het is wel een stukje service dat je er bij verwacht.

Net zoals, naar mijn mening, je zou kunnen verwachten dat iemand die Facebook-apps ontwikkeld ook op de hoogte is van aankomende veranderingen in de API. En je daar als klant over informeert als je iets aanschaft.

[Firesphere]

HuHu schreef op donderdag 31 juli 2014 @ 16:30:
[...]

Het zou een dealer sieren als hij erbij vermeld dat het circuit wordt gesloten. Je kunt hem niets aanrekenen, maar het is wel een stukje service dat je er bij verwacht.

Net zoals, naar mijn mening, je zou kunnen verwachten dat iemand die Facebook-apps ontwikkeld ook op de hoogte is van aankomende veranderingen in de API. En je daar als klant over informeert als je iets aanschaft.

Facebook doet vaak dingen deprecaten op week's notice hor. Als er te weinig gebruik van wordt gemaakt (naar hun zin), dan flikkeren ze het gewoon er uit. En daar doe je dus helemal niets aan.

Daarnaast kun je op dit moment geen enkele garantie geven dat de API nog werkt over een half jaar, dus die vlieger gaat echt niet op.

[.Gertjan.]

HuHu schreef op donderdag 31 juli 2014 @ 16:30:
[...]
Net zoals, naar mijn mening, je zou kunnen verwachten dat iemand die Facebook-apps ontwikkeld ook op de hoogte is van aankomende veranderingen in de API. En je daar als klant over informeert als je iets aanschaft.

En je dacht dat ik niets beters te doen had dan iedere dag die blogs van die gasten te volgen? Ik neem aan dat als je een API een versie geeft dat deze gewoon een tijd blijft leven. Nee, zegt Facebook. We verplichten je om een v1.0 prefix te gebruiken voor oude calls, de calls zonder versie gaan nu naar v2.0. En ow ja, over een tijd trekken we v1.0 eruit, zonder echte reden (dit was al een breaking change eerder).

Waarom kunnen bedrijven als Microsoft wel hun API's compatible houden? Kijk soms zal er een bug op kunnen treden in een oude versie, maar geloof mij, als Microsoft oude API's een jaar na de release eraf gooit en je verplicht te upgraden dan is de wereld te klein. Een public API moet gewoon stabiel en robuust zijn. Kun je dat niet garanderen, slinger er dan een label op met Beta.

Facebook is niet mijn primaire bron en er kan niet verwacht worden dat je op de hoogte blijft. En als je dat wilt, verplicht developers dan hun mail op te geven en mail ze over zulke dingen. Het besluit om na een bepaalde datum v1.0 gebruik niet toe te staan voor nieuwe apps is echt te zot voor woorden, stel dat je eerst met een test appje werkte en dan naar productie wilt via een nieuwe app, helaas dat kan dus niet.

Dat ze het gratis weggeven betekent niet dat ze zomaar de hufter mogen uithangen... Het feit dat je de gegevens wel kunt verkrijgen als vertrouwde partner maakt het geheel nog vreemder in mijn ogen.

By the way: het is geen facebook app, het is een facebook integratie. Ik communiceer enkel met hun API en verder heb ik er gelukkig weinig mee te maken. Mijn beroep is geen facebook app developer en dat ambieer ik ook absoluut niet.

[ Voor 6% gewijzigd door .Gertjan. op 31-07-2014 16:39 ]

[ZaZ]

Ger schreef op donderdag 31 juli 2014 @ 16:22:
[...]

Inderdaad. Zie het zo:

Klant koopt bij dealer een mooie wagen om op circuit mee te rijden. Dealer geeft advies voor goede wagen voor dat circuit. Klant krijgt wagen afgeleverd, circuit wordt gesloten.
Dan heeft die klant gewoon pech en de dealer valt niets aan te rekenen. Hooguit dat je wat coulance kunt krijgen bij inruil.

Vind ik persoonlijk een beetje kort door de bocht. De klant is geen developer en weet dus misschien niet eens wat een API is. Die verwacht gewoon dat het blijft werken zolang Facebook blijft werken.
De klant neemt functionaliteit af bij jou als leverancier en jij wordt geacht die functionaliteit te leveren of je moet de regeltjes heel goed dichttimmeren en de klant op de hoogte stellen van de risico's. Anders ga je maar scrapen of iets dergelijks om ervoor te zorgen dat het werkt.

[Firesphere]

Twitter heeft ook "gewoon" de stekker uit hun api 1.0 getrokken. Weliswaar aangekondigt, maar dat was ook "doei"

Zo'n bedrijf is helemaal NIETS aan jou verplicht. Met het aanbieden van een gratis API doen ze aardig, maar het is data op hun servers. Ze mogen wat dat betreft op elk moment er de stekker uittrekken.

ZaZ schreef op donderdag 31 juli 2014 @ 16:43:
[...]

Vind ik persoonlijk een beetje kort door de bocht. De klant is geen developer en weet dus misschien niet eens wat een API is. Die verwacht gewoon dat het blijft werken zolang Facebook blijft werken.
De klant neemt functionaliteit af bij jou als leverancier en jij wordt geacht die functionaliteit te leveren of je moet de regeltjes heel goed dichttimmeren en de klant op de hoogte stellen van de risico's. Anders ga je maar scrapen of iets dergelijks om ervoor te zorgen dat het werkt.

Zoals ik al zei, als jij niet aftimmert dat je niet verantwoordelijk bent voor het functioneren van 3rd-party applicaties ben je een ongelofelijk domme idioot.

Nee, je gaat niet scrapen, op't moment dat een API niet meer werkt. Dat kan zelfs niet eens altijd.

API er uit? Jammer, maar an werkt het niet meer. Zie contract, veel plezier.

[dcm360]

ZaZ schreef op donderdag 31 juli 2014 @ 16:43:
[...]

Vind ik persoonlijk een beetje kort door de bocht. De klant is geen developer en weet dus misschien niet eens wat een API is. Die verwacht gewoon dat het blijft werken zolang Facebook blijft werken.
De klant neemt functionaliteit af bij jou als leverancier en jij wordt geacht die functionaliteit te leveren of je moet de regeltjes heel goed dichttimmeren en de klant op de hoogte stellen van de risico's. Anders ga je maar scrapen of iets dergelijks om ervoor te zorgen dat het werkt.

Ik vind dat je een verkeerd product verkoopt als je niet aangeeft dat het afhankelijk is van een derde partij die nogal wat grillen vertoont.
Overigens, als je gaat scrapen is het waarschijnlijk veel vaker stuk dan dat een deel van de API ineens verdwijnt. Een betere oplossing is een compromis sluiten met de klant, er vanuitgaande dat je verprutst hebt wat ik in mijn eerste alinea noemde.

[.Gertjan.]

Firesphere schreef op donderdag 31 juli 2014 @ 16:45:
Zo'n bedrijf is helemaal NIETS aan jou verplicht. Met het aanbieden van een gratis API doen ze aardig, maar het is data op hun servers. Ze mogen wat dat betreft op elk moment er de stekker uittrekken.

Verplicht is een groot woord. Maar een API aanbieder heeft natuurlijk wel macht. Stel jij bouwt iets wat men daar erg interessant vind. Als men wil zagen ze gewoon de poten onder de API uit en drukken ze jou de markt af. Als ze zien dat er geld te verdienen is met keyword analyse, trekken ze daar de stekker uit de gratis kant en gaan ze het commercieel maken (wat ik vermoed dat hier aan de hand is). Het klopt dat ze daar wel het volle recht toe hebben, maar of het moreel verantwoord is, dat weet ik zo net nog niet.

Door integraties met FB zorg ik ook voor inkomsten voor hen, verkeer/communicatie loopt via Facebook en Facebook krijgt revenue vanwege namedropping en gebruik. Door de software die ik maak, registreren mensen/bedrijven/whatever zich op Facebook en consumeren ze daar content en kunnen ze reclames gepresenteerd worden. Nu zal dat peanuts zijn in mijn geval, maar doe dat eens maal duizenden kleine bedrijfjes. Als je dan vervolgens de API saboteert heb je dus wel genomen van je consumerende partijen en wijs je ze daarna de deur....

Hoewel het dus allemaal legaal is, zou het niet mijn business model zijn.

[ZaZ]

Firesphere schreef op donderdag 31 juli 2014 @ 16:45:
Twitter heeft ook "gewoon" de stekker uit hun api 1.0 getrokken. Weliswaar aangekondigt, maar dat was ook "doei"

Zo'n bedrijf is helemaal NIETS aan jou verplicht. Met het aanbieden van een gratis API doen ze aardig, maar het is data op hun servers. Ze mogen wat dat betreft op elk moment er de stekker uittrekken.


[...]

Zoals ik al zei, als jij niet aftimmert dat je niet verantwoordelijk bent voor het functioneren van 3rd-party applicaties ben je een ongelofelijk domme idioot.

Nee, je gaat niet scrapen, op't moment dat een API niet meer werkt. Dat kan zelfs niet eens altijd.

API er uit? Jammer, maar an werkt het niet meer. Zie contract, veel plezier.

Volgens mij zitten we wel op 1 lijn hoor. Ik bedoel ook te zeggen dat als je de klant NIET op de hoogte stelt en de boel dichttimmert, dan ben je gewoon verantwoordelijk en dan moet je maar creatief gaan doen ofzo of er op een andere manier uit proberen te komen, maar die kost vaak dikke centen.

[vpm]

Aaand time! Inpakken en wegwezen.

[ZaZ]

vpm schreef op donderdag 31 juli 2014 @ 17:01:
Aaand time! Inpakken en wegwezen.

ambtenaar

[Caelorum]

ZaZ schreef op donderdag 31 juli 2014 @ 17:11:
[...]
ambtenaar

Nee, die staan om 4 uur toch al in de rij met de auto? ^^

[ZaZ]

Caelorum schreef op donderdag 31 juli 2014 @ 17:21:
[...]

Nee, die staan om 4 uur toch al in de rij met de auto? ^^

Ok, ambtenarenmentaliteit dan

[.oisyn]

Douweegbertje schreef op donderdag 31 juli 2014 @ 15:59:
[...]


Je zult maar niet begrijpen dat wat hier gepost is niet letterlijk naar de klant gaat.

"Firesphere schreef...". Je weet van wie het kwam, he

Firesphere schreef op donderdag 31 juli 2014 @ 16:32:
[...]

Facebook doet vaak dingen deprecaten op week's notice hor.

Dat is iets waar je als developer van op de hoogte bent. Het is imho een common courtesy dat je dat ook naar de klant communiceert, zodat de klant weet wat de risico's zijn.

[ Voor 39% gewijzigd door .oisyn op 31-07-2014 17:38 ]

[Douweegbertje]

Ok, dat is een valide punt.

on serious note; net even gezellig met adwords vrouwtje lopen bellen. Leuke stem, snapt het ook allemaal nog, natuurlijk even verder gezocht en facebook gevonden, zag er ook prima uit.
Zo, dat was het stalker stukje, nu even de rant.

Kon ten eerste geen IBAN nummer invullen want hij vond het allemaal maar niets. Uiteindelijk half uurtje later geprobeerd en toen werkte het wel. Vervolgens ga ik maar een campagne aanmaken.. en bam google error. Alles kwijt (best wel wat stappen). Vervolgens nog een keer.. weer een error..
Toen opeens kwam er een flash melding dat er een 'nieuwe versie' is, en dat je even moet F5'en om het te zien. En voila alles ging weer goed.
Leuk hoor, changes online zetten als ik een campagne aan het maken ben..

Verder tijdje geleden dat ik iets met adwords heb gedaan, moet zeggen dat de service een stuk beter is. Boven de 10,- p/d helpen ze je met alles goed zetten, en daaronder kun je het zelf doen en doen ze daarna een 'check' met advies en dat soort meuk. Direct contact, telefoon/e-mail etc. Puike service al zeg ik het zelf.
Deden ze dat nou ook maar bij adsense

[ Voor 95% gewijzigd door Douweegbertje op 31-07-2014 17:51 ]

[Firesphere]

.Gertjan. schreef op donderdag 31 juli 2014 @ 16:50:
[...]
Door integraties met FB zorg ik ook voor inkomsten voor hen, verkeer/communicatie loopt via Facebook en Facebook krijgt revenue vanwege namedropping en gebruik. Door de software die ik maak, registreren mensen/bedrijven/whatever zich op Facebook en consumeren ze daar content en kunnen ze reclames gepresenteerd worden. Nu zal dat peanuts zijn in mijn geval, maar doe dat eens maal duizenden kleine bedrijfjes. Als je dan vervolgens de API saboteert heb je dus wel genomen van je consumerende partijen en wijs je ze daarna de deur....

Hoewel het dus allemaal legaal is, zou het niet mijn business model zijn.

Even wachten hoor...

Jij zegt dus eigenlijk:
"Ik gebruik informatie van een ander commercieel bedrijf (fb/twitter/li, whatever), die ze toevallig gratis aanbieden via een API, om zo zelf geld te verdienen.
Ik vind het hun morele verplichting om er voor te zorgen dat ik mijn geld kan blijven verdienen"?

Dat is best een bijzondere stelling eerlijk gezegd.

.oisyn schreef op donderdag 31 juli 2014 @ 17:33:
[...]

"Firesphere schreef...". Je weet van wie het kwam, he

[...]

Dat is iets waar je als developer van op de hoogte bent. Het is imho een common courtesy dat je dat ook naar de klant communiceert, zodat de klant weet wat de risico's zijn.

Klopt, maar dat is niet wat ik bedoelde. Als een applicatie 2 jaar goed draait, maar de gebruikte API gaat dicht, is dat niet een reden om het maar gratis te repareren.

Op welke termijn de notice komt, is in dat opzicht wat mij betreft oninteressant. Tenzij het gebeurd terwijl je nog aan het ontwikkelen bent.

[Alex)]

Niets zo vervelend als er 10 minuten voor je naar huis wilt gaan achterkomen dat iets zeer belangrijks is omgevallen, en je morgen een demo moet geven

[Verwijderd]

Nou als je pas erachter komt als je de demo moet geven is het toch net iets minder fijn

[Firesphere]

https://srlabs.de/badusb/
O_o

[Verwijderd]

nieuws: Onderzoekers kraken firmware usb-controllers

[Firesphere]

Verwijderd schreef op donderdag 31 juli 2014 @ 21:03:
nieuws: Onderzoekers kraken firmware usb-controllers

Mja, FP kijk ik niet altijd.

[.Gertjan.]

Firesphere schreef op donderdag 31 juli 2014 @ 18:25:
[...]

Even wachten hoor...

Jij zegt dus eigenlijk:
"Ik gebruik informatie van een ander commercieel bedrijf (fb/twitter/li, whatever), die ze toevallig gratis aanbieden via een API, om zo zelf geld te verdienen.
Ik vind het hun morele verplichting om er voor te zorgen dat ik mijn geld kan blijven verdienen"?

Dat is best een bijzondere stelling eerlijk gezegd.

Kletskoek. Teneerste blijf ik er geen geld aan verdienen. Daarnaast zal hij mij een rotzorg zijn als FB morgen omdondert, mijn omzet komt gelukkig grotendeels uit hele andere bronnen, dit was leuk voor erbij. En hoewel ze het gratis weggeven verdienen ze er echt wel aan hoor. Ik vind dat als je iets publiek maakt, je daar ook verantwoordelijkheid voor moet nemen (tot op bepaalde hoogte). Wat dat betreft is een API gewoon een soort standaard, je kunt niet om de haverklap je standaarden aanpassen, wel? Daarnaast gebruik ik niet hun informatie, maar in veel gevallen notabene de informatie van de eindgebruikers zelf, sinds wanneer is dat van Facebook? Ik zorg er voor dat ze bijvoorbeeld zaken naar FB kunnen posten. Hierdoor krijgen bedrijven een presence op het medium, wat weer revenue oplevert voor FB. Het argument: "ze geven het gratis weg, dus je mag niets verlangen" is wat mij betreft kolder. Daarnaast is het niet dat ze het "toevallig" weggeven, het is notabene een selling point van hun api's geweest, maar nu slaan ze dat soort dingen er onderuit. Beetje bijzonder, zeker omdat je als vertrouwde partner het nog wel kunt krijgen (waarschijnlijk tegen dikke knaken)... En wat als het wel een betaalde dienst was, was je mening dan gelijk? Ik wil gerust betalen voor dit soort API's, maar dan wel ten gunste van stabiliteit.

Tuurlijk is het hun recht maar dat het mag betekent niet dat je het moet doen Als je iets publiek maakt horen daar imo ook verantwoordelijkheden bij. Ongeacht of het gratis of betaald is.

Daarnaast vergeet men ook, dat als ze de developers maar genoeg tegen de haren in wrijven ze uiteindelijk vertrekken. Dus op de lange termijn gaan ze dat wel merken. Als de integratie zo'n drama is, zullen steeds minder mensen het een aantrekkelijk platform vinden. Je ziet wel vaker dat een populair medium ineens de deur wordt gewezen door grote groepen developers. Als v1.0 straks verdwijnt zal de eerste groep developers snel afhaken vrees is.

Ik denk niet dat wij het met elkaar eens gaan worden, maar ik vind het een beetje een naaiactie van ze. In mijn ogen steken ze gewoon de middelvinger op tegen de developers. Ik ben er zelf in ieder geval redelijk klaar mee. Geloof mij, ik wil ook gewoon liever mijn systemen stabiel houden en niet steeds met het vingertje naar FB moeten wijzen. Dan trek ik mij liever terug uit die markt.

[Douweegbertje]

Ik ben het deels met Gerjan eens. Het is niet zomaar een API waar iemand data van pulled voor eigen gebruik en hier winst op pakt. Vrijwel 9 van de 10 keer heeft het meer positieve effecten voor FB zelf dan de gene die de API gebruikt. In feite is het dan niet slim om het zomaar te veranderen. Dit is dus waarom ik zei "deels mee eens"; ik vind namelijk dat FB het allemaal wel redelijk doet met hun API.
Heel dat verhaal van v1 vs v2 is redelijk lang bekend.. volgens mij al sinds het begin van dit jaar (of zelfs eind 2013..). Verder staat het er ook nog eens vrij duidelijk in hoe dingen werken als in ; nieuwe apps na mei/april oid gebruiken standaard v2.. apps daarvoor zonder versie aanduiding gebruiken weer v1.

Dus hoewel ik je rant snap, slaat de rant naar mijn mening eerder op je zelf dat je na 7 maanden nog niet doorhebt dat v1 deprecated is..

Hun laten v1 gewoon meer als één jaar(!!!) live staan, dat is wel bizar lang hoor...


---------------------

M'n adwords campagne..
Het aantal vertoningen is opeens omlaag gegaan.. had er eerst 300, nu iets van 240 Ding spoort vandaag niet helemaal denk ik.

-----------------

En wat..? Gast heeft mij gebeld oid

[ Voor 12% gewijzigd door Douweegbertje op 31-07-2014 22:22 ]

[Firesphere]

Douweegbertje schreef op donderdag 31 juli 2014 @ 21:54:
Ik ben het deels met Gerjan eens. Het is niet zomaar een API waar iemand data van pulled voor eigen gebruik en hier winst op pakt. Vrijwel 9 van de 10 keer heeft het meer positieve effecten voor FB zelf dan de gene die de API gebruikt. In feite is het dan niet slim om het zomaar te veranderen. Dit is dus waarom ik zei "deels mee eens"; ik vind namelijk dat FB het allemaal wel redelijk doet met hun API.
Heel dat verhaal van v1 vs v2 is redelijk lang bekend.. volgens mij al sinds het begin van dit jaar (of zelfs eind 2013..). Verder staat het er ook nog eens vrij duidelijk in hoe dingen werken als in ; nieuwe apps na mei/april oid gebruiken standaard v2.. apps daarvoor zonder versie aanduiding gebruiken weer v1.

Dus hoewel ik je rant snap, slaat de rant naar mijn mening eerder op je zelf dat je na 7 maanden nog niet doorhebt dat v1 deprecated is..

Hun laten v1 gewoon meer als één jaar(!!!) live staan, dat is wel bizar lang hoor...

Nou ja, dat vind ik dus niet. Een API is van jou, en als je besluit bepaalde data niet meer door te geven, is dat aan jezelf.

Dat dat irritant/kut/klote is voor de developers, tja, sorry, so be it. Helemaal als het ruimschoots is aangekondigt.

@.Gertjan.:
Je bracht het wel een beetje op die manier En je mag het gerust met me oneens zijn hoor, maar ik vind dat de maker van de API mag bepalen wat er wordt doorgegeven.

[farlane]

Firesphere schreef op donderdag 31 juli 2014 @ 22:31:
@.Gertjan.:
Je bracht het wel een beetje op die manier En je mag het gerust met me oneens zijn hoor, maar ik vind dat de maker van de API mag bepalen wat er wordt doorgegeven.

Vind je dat dit ook geldt voor bijvoorbeeld de Win32 API? De C library API? Feitelijk is dat eenzelfde situatie.

[Firesphere]

farlane schreef op donderdag 31 juli 2014 @ 22:40:
[...]

Vind je dat dit ook geldt voor bijvoorbeeld de Win32 API? De C library API? Feitelijk is dat eenzelfde situatie.

In principe wel, ja. Er zit alleen wel een verschil tussen een local-system en data van een ander inlezen.

[Ealanrian]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 6% gewijzigd door Ealanrian op 31-07-2014 23:07 ]

[Firesphere]

Ealanrian schreef op donderdag 31 juli 2014 @ 23:03:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Ja, bereid je maar ontspannen voor op een hoop kleine lettertjes!

Anders past het niet op 1 A4

[NMe]

Pff, latertje vanavond. Iets met een klant die sneller tickets inschiet dan ik ze op kan lossen en morgen een belangrijke presentatie heeft.



Morgen toch maar een half dagje doen.

[Ealanrian]

Gelukkig kan ik goed lezen en zijn kleine lettertjes meestal geen probleem

[Firesphere]

Pro-tip:
Stel Memcached niet in op 1024, als je maar 512MB aan RAM totaal hebt. Daar wordt je server verrekte traag van.

[Ealanrian]

Firesphere schreef op donderdag 31 juli 2014 @ 23:13:
Pro-tip:
Stel Memcached niet in op 1024, als je maar 512MB aan RAM totaal hebt. Daar wordt je server verrekte traag van.

memchached op de rpi?

[Firesphere]

Ealanrian schreef op donderdag 31 juli 2014 @ 23:17:
[...]

memchached op de rpi?

Uiteraard Hoe dacht je anders dat ik die response zo snel heb voor een Pi?

[Douweegbertje]

Ealanrian schreef op donderdag 31 juli 2014 @ 23:17:
[...]

memchached op de rpi?

Ik gebruik het voor een webapp met memcached als 'deamon' en memcache als 'client' aka library. Je wordt overigens helemaal leip van die benamingen.. Maar in elk geval kun je het zowat al gebruiken met 50Mb.. Tis maar net wat je doet.
Beetje basic data uit de DB kan bijv. zo'n 50mb zijn..

Volgens mij verbruik ik niet meer dan 150Mb, en er zit best veel data in.

[Firesphere]

Douweegbertje schreef op donderdag 31 juli 2014 @ 23:39:
[...]


Ik gebruik het voor een webapp met memcached als 'deamon' en memcache als 'client' aka library. Je wordt overigens helemaal leip van die benamingen.. Maar in elk geval kun je het zowat al gebruiken met 50Mb.. Tis maar net wat je doet.
Beetje basic data uit de DB kan bijv. zo'n 50mb zijn..

Volgens mij verbruik ik niet meer dan 150Mb, en er zit best veel data in.

Klopt, alleen als je een foutje maakt, reserveerd'ie z'n geheugen, dat is dus wat ik deed

Al opgelost, weer netjes 128MB aan RAM, daar moet'ie wel mee vooruit kunnen.

[Douweegbertje]

huh, wat is de fout die je hebt gemaakt dan? Had je zoveel 'nieuwe' data dan? In feite allocate memcached pas een volledige slab als je het vult met data.

[Firesphere]

Douweegbertje schreef op vrijdag 01 augustus 2014 @ 00:07:
huh, wat is de fout die je hebt gemaakt dan? Had je zoveel 'nieuwe' data dan? In feite allocate memcached pas een volledige slab als je het vult met data.

Pre-allocating aangezet dus, zoals ik zei

[Douweegbertje]

argh. dat moment dat alles fout gaat -,-'
Domein aan het verhuizen incl. hosting naar ander account. Goed, dat account had al een dev achtig domein inclusief hosting. Alles was klaar gezet en werkte daar.
Nu mag je maar één domein op dat pakket, dus ik doe een interne push van het domein. Op het andere account weer een push.
Wat gebeurde er nu, dat ding pushte ook de hosting mee van het dev domain waar de site op moet komen

Niet zo erg, behalve dat nu het echte domein er wel naar toe gaat en 'elk moment kan arriveren'...
Snel weer hosting gekocht, andere opgezegd (niet zo erg, ging toch per maand.. scheelt toevallig 1 dag). Site 'weer' gedeployed, maar ik kan het niet testen omdat het IP een domme 'banner' geeft dat het domein gereserveerd.

Nu wachten maar tot ik eindelijk kan zien of alles nog werkt

[Firesphere]

Douweegbertje schreef op vrijdag 01 augustus 2014 @ 00:44:
argh. dat moment dat alles fout gaat -,-'
Domein aan het verhuizen incl. hosting naar ander account. Goed, dat account had al een dev achtig domein inclusief hosting. Alles was klaar gezet en werkte daar.
Nu mag je maar één domein op dat pakket, dus ik doe een interne push van het domein. Op het andere account weer een push.
Wat gebeurde er nu, dat ding pushte ook de hosting mee van het dev domain waar de site op moet komen

Niet zo erg, behalve dat nu het echte domein er wel naar toe gaat en 'elk moment kan arriveren'...
Snel weer hosting gekocht, andere opgezegd (niet zo erg, ging toch per maand.. scheelt toevallig 1 dag). Site 'weer' gedeployed, maar ik kan het niet testen omdat het IP een domme 'banner' geeft dat het domein gereserveerd.

Nu wachten maar tot ik eindelijk kan zien of alles nog werkt

Mijn ervaringen met je provider zijn dat dat nog wel eens een tijdje kon duren. Ik heb vaak het idee dat ze de zaken niet goed voor elkaar hebben.

[Matis]

Zo, vanaf vandaag ga ik via mijn SSH proxy internetten op de zaak. Vannacht zijn ze overgegaan op een nieuwe ISP met een filter dat zo'n beetje alle websites waar ik normaal (ook zakelijk) op zit blokkeert. Sowieso webverkeer dat niet over poort 80 of 443 gaat wordt geblokt.
Zojuist aangegeven bij ICT dat ik de helft van mijn werk niet meer kan doen zonder die sites.

Zij gaven aan dat de ISP bepaalt welke websites er wel en niet doorheen komen (iets met certificering ofzo).

Prima, dan maar tunnelen via thuis.

[Caelorum]

Lekker veel nut hebben al die "blokkades" ook zeg

[Alex)]

Één van de mooiste dingen die ik ben tegengekomen blijft toch wel een klant waar ze ook zo'n proxy hadden die veel nuttige pagina's blokkeerde. Ik kon er niet zonder proxyserver op internet kon komen, maar ik kon wel een proxyserver instellen die zich buiten het bedrijfsnetwerk bevond.

Squid op een VPS en gaan met die banaan. Enige nadeel is dat ik ineens veel advertenties in het Duits kreeg te zien, want die VPS draaide ergens nabij Frankfurt.

[ZaZ]

Caelorum schreef op vrijdag 01 augustus 2014 @ 08:12:
Lekker veel nut hebben al die "blokkades" ook zeg

Dat soort blokkades slaan over het algemeen echt nergens op. Ik was ook een keer ergens en daar hadden ze alles potdicht gezet. Alles ging ook nog via een proxy en enkel HTTPS werd toegestaan. Ik een tunnel proberen op te zetten via SSH naar thuis maar poort 22 ook geblokkeerd met melding SSH verkeer niet toegestaan. Fijn, draai ik toch mijn server ook via poort 443?
SSH opzetten via 443 naar huis en het volledige internet weer beschikbaar. Security through obscurity

[.Gertjan.]

Douweegbertje schreef op donderdag 31 juli 2014 @ 21:54:
Dus hoewel ik je rant snap, slaat de rant naar mijn mening eerder op je zelf dat je na 7 maanden nog niet doorhebt dat v1 deprecated is..

Ik wist dat het deprecated was en zou vervallen per 1 mei 2015. Dat men de regels aanpast en besluit nieuwe applicaties niet meer in v1 toe te laten was wel onverwachts. Het punt is dat ik vaak met een test versie werk en als het goed is dan een productie app aanmaakt. Daarnaast hebben ze de achterlijke beperking dat je maar 1 domein mag registreren in je app... Dus als je meerdere domeinen hebt waar je gaat hosten moet je nieuwe apps maken, en dat is nu dus een probleem. Het feit dat ze ruim na de aankondiging besluiten om v1 verder te locken is gewoon klote en niet direct gecommuniceerd (ja uiteindelijk wel, maar ik heb meer te doen dan te lopen f5-en op hun blog/docs).

Ja uiteindelijk is het beland op de roadmap pagina, maar daar heeft het niet vanaf het begin gestaan.

Hun laten v1 gewoon meer als één jaar(!!!) live staan, dat is wel bizar lang hoor...

Een jaar is lang? Misschien moet je eens even door de API's van Windows/.NET lopen, daar zit spul in wat veel ouder is. Ow en Microsoft geeft hun API's ook nog gratis weg! Daarnaast is het wel redelijk snel om iets wat deprecated is meteen in de volgende versie eruit te wippen. Vaak zie je dat er in v1 volle support is, v2 support en deprecated, v3 removed. Nu hebben ze met terugwerkende kracht in v1 iets deprecated gemaakt en het uit v2 gewipt.

Jullie hebben volkomen gelijk dat ze mogen doen wat ze willen omdat het hun api is. Maar ik vind zelf dat als ik een API release dat hier ook gewoon een stukje support/verantwoordelijkheid bij hoort. Daarnaast is een jaar best kort voor nieuwe versies. Niet iedereen heeft een flitsende app die on the fly wordt voorzien van updates. Mijn software draait binnen grotere bedrijven, die lopen soms meer dan een jaar achter met migraties/updates. Verkeerd? Zal wel, maar grote bedrijven laten zich niet rushen. Aangezien ik echt niet de enige ben die Facebook integreert in grotere backend applicatie vind ik het persoonlijk nogal onvoorzichtig. Maar goed, dat is mijn mening en ik zou zelf een andere houding aannemen.

[Blubber]

.Gertjan. schreef op vrijdag 01 augustus 2014 @ 09:47:
[...]
Een jaar is lang? Misschien moet je eens even door de API's van Windows/.NET lopen, daar zit spul in wat veel ouder is. Ow en Microsoft geeft hun API's ook nog gratis weg! Daarnaast is het wel redelijk snel om iets wat deprecated is meteen in de volgende versie eruit te wippen. Vaak zie je dat er in v1 volle support is, v2 support en deprecated, v3 removed. Nu hebben ze met terugwerkende kracht in v1 iets deprecated gemaakt en het uit v2 gewipt.
[...]

Ik zie dat niet direct als een voordeel, dit is een van de redenen dat we nog steeds in het stenen tijdperk leven. Backwards compatibility is handig, maar het heeft wel de potentie om vooruitgang tegen te houden. Daar komt ook nog eens bij dat het steeds moeilijker wordt om nog naar een nieuwe versie over te stappen. Als je de boel up-to-date houdt is de kans groot dat je vaker, kleinere aanpassingen doet, in plaats van af en toe grote verbouwingen.

[Korben]

.Gertjan. schreef op vrijdag 01 augustus 2014 @ 09:47:
[...]
Jullie hebben volkomen gelijk dat ze mogen doen wat ze willen omdat het hun api is. Maar ik vind zelf dat als ik een API release dat hier ook gewoon een stukje support/verantwoordelijkheid bij hoort.

Eens, zodra je (zeker als groot bekend bedrijf, wat Facebook is) een API publiekelijk toegankelijk maakt moet deze bevroren blijven, op een dergelijke manier dat alle functies die bij het releasen aanwezig zijn, aanwezig blijven tot de API-versie in z'n geheel deprecated wordt.

Blubber schreef op vrijdag 01 augustus 2014 @ 10:04:
[...]


Ik zie dat niet direct als een voordeel, dit is een van de redenen dat we nog steeds in het stenen tijdperk leven. Backwards compatibility is handig, maar het heeft wel de potentie om vooruitgang tegen te houden. Daar komt ook nog eens bij dat het steeds moeilijker wordt om nog naar een nieuwe versie over te stappen. Als je de boel up-to-date houdt is de kans groot dat je vaker, kleinere aanpassingen doet, in plaats van af en toe grote verbouwingen.

Ja leuk, maar wie gaat dat betalen? Als Microsoft, of in dit geval Facebook, besluit dat een API deprecated is; wie gaat het updaten van de code betalen? De klant kan het geen flikker schelen dat Facebook er ongetwijfeld een goede reden voor had. Jij als ontwikkelaar evenmin, en Facebook gaat er zeker niet voor betalen. Conclusie: niemand gaat er voor willen betalen, dus er wordt niks geüpdatet.

[ZaZ]

Blubber schreef op vrijdag 01 augustus 2014 @ 10:04:
[...]
Ik zie dat niet direct als een voordeel, dit is een van de redenen dat we nog steeds in het stenen tijdperk leven. .. <knip>

Stenen tijdperk? Voorbeeld graag, ben gewoon benieuwd.
Ik heb redelijk veel recht tegen de Win32 API aangeprogged en vaak heb je gewoon 'weg' era 9x en NT of XP+ om ergens te komen.

[Blubber]

ZaZ schreef op vrijdag 01 augustus 2014 @ 10:08:
[...]

Stenen tijdperk? Voorbeeld graag, ben gewoon benieuwd.
Ik heb redelijk veel recht tegen de Win32 API aangeprogged en vaak heb je gewoon 'weg' era 9x en NT of XP+ om ergens te komen.

Het was niet bedoeld als microsoft rant, het was meer een algemene opmerking. Maar een voorbeeld is de vervanging van de BIOS, of de vervanging van PATA. Een ander voorbeeld is het feit dat de micro USB nog steeds gebruikt wordt, en plug die maar in 1 richting in je apparaat kan is toch niet echt meer van deze tijd.

Nogmaals, ik snap wel waarom het op deze manier gaat, mijn punt is niet dat het anders moet, maar dat het wel anders kan en dat dat voordelen met zich mee brengt (en nadelen, zoals Gertjan ondervonden heeft ).

[dcm360]

Blubber schreef op vrijdag 01 augustus 2014 @ 10:20:
[...]
Maar een voorbeeld is de vervanging van de BIOS, of de vervanging van PATA.

Wat had je hier dan graag gezien? Geen ondersteuning meer geven voor de oude standaard zodat de nieuwe producten door geen hond gekocht worden?

[Blubber]

dcm360 schreef op vrijdag 01 augustus 2014 @ 11:34:
[...]

Wat had je hier dan graag gezien? Geen ondersteuning meer geven voor de oude standaard zodat de nieuwe producten door geen hond gekocht worden?

Wikipedia: False dilemma

[.Gertjan.]

dcm360 schreef op vrijdag 01 augustus 2014 @ 11:34:
[...]

Wat had je hier dan graag gezien? Geen ondersteuning meer geven voor de oude standaard zodat de nieuwe producten door geen hond gekocht worden?

Precies, dat is dus een goede reden om wel compatible te blijven. Ik heb thuis een hele la met oude USB connectors die ik weg kan donderen omdat er weer nieuwe kwamen (geloof dat ik 3 generaties kabels heb liggen). Nu is dat op een kabeltje geen probleem, maar als ik een computer upgrade en ik kan mijn schijven niet kwijt omdat ze naar 1337-XATA ofzo gaan, dan upgrade ik niet. Als ik mijn oude hardware allemaal moet vervangen blijf ik wel hangen (uiteraard het redelijk in acht nemen). Ik geloof dat PATA best wat jaren nog rond heeft gehangen en dat het pas recentelijk gebruikelijk is geworden om geen PATA meer te bieden.

Backwards compatibility zorgt er juist voor dat er groei en beweging komt Als ik straks alleen nog maar 3d films kan kopen ben ik verplicht een 3d tv en apparatuur te kopen. Nou sorry, dan maar geen films.

Grote bedrijven snappen dat ze voorzichtig moeten zijn met api's/standaarden die ze ooit publiceerden. Niet voor niets dat het vaak wat langer duurt voordat api's beschikbaar komen, want once-published zit je er aan vast. Schijnbaar neemt Facebook hun api niet echt serieus of zien ze gewoon niet wat de impact is. Upgraden is op zich geen probleem (met Twitter was dat snel gedaan), maar het weghalen van bepaalde zaken zonder een goed alternatief (iig voor kleine gebruikers) is gewoon niet tof.

[Voutloos]

In hetzelfde rijtje: Als De Wereld afspreekt dat het verboden is om vanaf 2015 apparaten uit te rusten met composiet, s-video, scart of vga zou het ook voor de grootste vooruitgang ooit zorgen.

(not gonna happen, en note de )

Overigens snap ik het wel dat Facebook geen nieuwe applications op een deprecated api toe staat. Dat is zo'n beetje de meest effictieve manier om courante apps over te krijgen en je helpdesk te ontlasten.

[ Voor 38% gewijzigd door Voutloos op 01-08-2014 11:46 ]

[Matis]

Voutloos schreef op vrijdag 01 augustus 2014 @ 11:44:
In hetzelfde rijtje: Als De Wereld afspreekt dat het verboden is om vanaf 2015 apparaten uit te rusten met composiet, s-video, scart of vga zou het ook voor de grootste vooruitgang ooit zorgen.

Gisteren nog een groot aantal ADCs verscheept voor diverse televisiestudio's, dus langzaamaan gaat het de goede kant op.

[Blubber]

.Gertjan. schreef op vrijdag 01 augustus 2014 @ 11:43:
[...]

Precies, dat is dus een goede reden om wel compatible te blijven. Ik heb thuis een hele la met oude USB connectors die ik weg kan donderen omdat er weer nieuwe kwamen (geloof dat ik 3 generaties kabels heb liggen). Nu is dat op een kabeltje geen probleem, maar als ik een computer upgrade en ik kan mijn schijven niet kwijt omdat ze naar 1337-XATA ofzo gaan, dan upgrade ik niet. Als ik mijn oude hardware allemaal moet vervangen blijf ik wel hangen (uiteraard het redelijk in acht nemen). Ik geloof dat PATA best wat jaren nog rond heeft gehangen en dat het pas recentelijk gebruikelijk is geworden om geen PATA meer te bieden.

Nee, dat is geen goede reden, sterker nog, het is een drogreden.

Ik heb nooit gezegt dat het huidige systeem geen voordelen heeft. Het is inderdaad vrij irritant als je contant alles nieuw moet kopen. Mijn enige punt was dat backwards compatibility een zeker traagheid introduceert.

.Gertjan. schreef op vrijdag 01 augustus 2014 @ 11:43:
Backwards compatibility zorgt er juist voor dat er groei en beweging komt Als ik straks alleen nog maar 3d films kan kopen ben ik verplicht een 3d tv en apparatuur te kopen. Nou sorry, dan maar geen films.

Wederom, ik zeg niet dat het altijd slecht is. Het enige wat ik zeg is dat het ook nadelen heeft. Dat wil niet zeggen dat er geen voordelen zijn.

.Gertjan. schreef op vrijdag 01 augustus 2014 @ 11:43:
Grote bedrijven snappen dat ze voorzichtig moeten zijn met api's/standaarden die ze ooit publiceerden. Niet voor niets dat het vaak wat langer duurt voordat api's beschikbaar komen, want once-published zit je er aan vast. Schijnbaar neemt Facebook hun api niet echt serieus of zien ze gewoon niet wat de impact is. Upgraden is op zich geen probleem (met Twitter was dat snel gedaan), maar het weghalen van bepaalde zaken zonder een goed alternatief (iig voor kleine gebruikers) is gewoon niet tof.

Nou ja, Google doet dit ook met bijvoorbeeld de AdWords API, ze sturen echter wel een mailtje naar gebruikers van oude APIs voordat ze die deprecaten.

[.Gertjan.]

Blubber schreef op vrijdag 01 augustus 2014 @ 11:50:
[...]
Nee, dat is geen goede reden, sterker nog, het is een drogreden.

Vind je? Wat maakt dat voor jou een drogreden? Ik vind het een perfecte reden om niet te upgraden, als ik een nieuw ding wil kopen, maar dat betekent dat ik meteen een hoop randapparatuur moet vervangen, dan vervang ik gewoon niet of ga ik zoeken naar een andere oplossing/leverancier.

Als een TV fabrikant straks besluit om geen < 1080p resoluties te ondersteunen dan laten veel mensen dat ding links liggen, want je kunt op dat moment direct vaarwel zeggen tegen een deel van je randapparatuur. Kan het wel mooi innovatief en hoogstaand zijn, maar zo werkt het niet.

Zaken backwards compatible houden is juist een verkoopargument. Het feit dat een Wii-u Wii spellen ondersteunt heeft mij dat ding doen aanschaffen, want anders had ik 2 consoles staan of had ik afscheid moeten nemen van mijn oude games.

Er zijn nu steeds 2 uitersten, namelijk dingen tot in de eeuwigheid moeten ondersteunen of dingen meteen obsolete maken. Volgens mij ligt het juiste pad ergens in het midden

[Blubber]

.Gertjan. schreef op vrijdag 01 augustus 2014 @ 11:56:
[...]

Vind je? Wat maakt dat voor jou een drogreden? Ik vind het een perfecte reden om niet te upgraden, als ik een nieuw ding wil kopen, maar dat betekent dat ik meteen een hoop randapparatuur moet vervangen, dan vervang ik gewoon niet of ga ik zoeken naar een andere oplossing/leverancier.
[...]

Het is een vals dilemma en een stropopargument.

[dcm360]

Dat is het niet. De vraag is: wil jij producten verkopen? De vervolgvraag is: wil je meer producten verkopen? En als dat lukt door ook oude technieken aan te bieden, dan doe je dat. Je bent als fabrikant of ontwikkelaar geen ideologische instelling, er moet brood op de plank.

[.Gertjan.]

Blubber schreef op vrijdag 01 augustus 2014 @ 12:01:
[...]
Het is een vals dilemma en een stropopargument.

Aan het bladeren geweest in je woordenboek/Wiki? Volgens mij worden hier op het topic steeds 2 uiterste aangehaald, of alles droppen of lang supporten. Ik ben van beide geen voorstander, ik leg alleen uit waarom ik niet meer tot aanschaf zal overgaan als ze de support droppen.

Dus dat is op geen enkele manier een stropargument wat mij betreft.

[Blubber]

.Gertjan. schreef op vrijdag 01 augustus 2014 @ 12:22:
[...]

Aan het bladeren geweest in je woordenboek/Wiki?

Wikipedia ja, ik vroeg mij namelijk af hoe dat ook alweer zat met de oorsprong van PostgreSQL. Maar wat heeft dat ermee te maken?