willemj

Een mobiele website is naast een 'normale' website heel goed te doen. Ben een webapplicatie aan het opleveren waar een gedeelte van de functionaliteit via een mobiele site bruikbaar is. Het werk voor de mobiele versie is grofweg 5-10% van het totaal. Je mist op deze manier alleen één (volgens mij) heel groot voordeel: de gebruiker heeft geen icoontje voor je site op zijn telefoon. Voor de iphone kun je nog wel zorgen dat een gebruiker via je site het icoontje kan maken maar niet voor android. Maar zelfs voor de iphone heb je dus een drempel voor de gebruiker op jouw icoontje kan klikken. Voor deze webapplicatie geen probleem omdat het mobiele gedeelte alleen voor personeel is. Maar voor generieke toepassingen zou ik deze drempel niet willen. Er zijn wel mogelijkheden om een mobiele webapplicatie te laten installeren via de appstore en 'google play'. Phonegap bijvoorbeeld. Je hebt daarmee geen toegang tot de geavanceerde functies van een mobiel maar de ontwikkeling is, zoals Frank zegt, een stuk voordeliger.

Als ik afspraken maak kom ik die ook na. Ik schrijf dus geen offerte uit met beloftes dat ik iets kan leveren op een bepaalde termijn om vervolgens te zeggen 'ja jammer iemand anders was eerder en betaalt beter dus je hebt pech'. Daarnaast kun je door een geldigheidsperiode op te nemen best wat te sturen en is een aanbod dat beperkt geldig is een standaard psychologisch middel om mensen over de streep te trekken. Denk maar aan de 'op=op' en 'alleen vandaag' kreten. Gezien de vorige reactie wel een interessant onderwerp de vrijblijvendheid van offertes. Misschien kan een mod de reacties hier even afsplitsen in een apart draadje 'offertes vrijblijvend of bindend'.

Zolang die niet geaccepteerd is, ja hoor. Zei degene die een klant voor de rechter daagde omdat deze op de valreep zijn aanbod introk :P (flauw ongenuanceerd grapje) Burgelijk wetboek 6:219 Ligt er dus aan hoe je je offerte opstelt. In mijn offertes staat een omschrijving van wat ik lever, tegen welk bedrag en meestal hoe lang de offerte geldig is. Bij elkaar is dat genoeg voor een onherroepelijk aanbod en kan ik die dus niet intrekken. Zie ook dit artikel.

Logmein gebruikt VNC voor de overbrengen van je beeld, Microsofts 'remote desktop' het RDP protocol. Wereld van verschil in hoe soepel het loopt. 'Remote desktop' over een paar Mb adsl line werkt prima.

Onderschat HTML niet :) HTML 5 heeft een geolocating api en een audio api. Mocht dat niet voldoen dan kun je met tools als Phonegap HTML applicaties maken die wat directer toegang hebben tot de hardware van het mobiele apparaat.

Definieer 'beter'. Minder initiele kosten, minder risico op kosten / veroordeling als je voor de rechter staat, meer kans om een zaak te winnen als het mis gaat, een klant die niet lacht als hij een in gebrekking Engels opgesteld contract voor ogen krijgt?

Denk dat Jeroen bedoelt 'laten vertalen'. Een vertaler kost 10-20 cent per woord (misschien 100-200 euro voor een eenvoudig contract?) Zelf pielen zou ik ook niet doen; zelfs in het Nederlands zijn juridische documenten soms al lastig.

Ik zou je eisen wat nuanceren. Als alles beschikbaar moet zijn op pc's en ipad's sluit je een hoop opties uit die in de praktijk waarschijnlijk beter zijn die voldoen aan deze eis. Als ik het zo snel lees zou je bijvoorbeeld je eigen machine zelf op afstand kunnen gebruiken met 'remote desktop' (hij staat waarschijnlijk toch altijd aan vanwege de mail), een aantal mappen kunnen delen met medewerkers die via een VPN op je modem verbinding maken met je netwerk en de mail ook toegankelijk maken via deze VPN. Kost je bijna niets (misschien éénmalig ander modem en andere versie van Windows voor 'remote desktop' en meer mogelijkheden voor het instellen van rechten) Dekt 90% van je verhaal maar niet de toegang met de ipad. Als je je werk opdeelt in taken en per taak kijkt wie, waar en wanneer die taak moet kunnen, of zou kunnen, uitvoeren dan krijg je een mooi lijstje waarop je de software kunt (laten) uitzoeken. Zet er dan meteen bij of het een 'must have' is of 'nice to have'; geen enkele oplossing gaat alles bieden wat je nodig denkt te hebben. Bijvoorbeeld: Bestellingen plaatsten: [wie] Daniel (must) / magazijnmedewerker (must) , [locatie] magazijn (must) / kantoor, (must) [wanneer] kantoortijd (must), thuis op de bank (nice) Verwerken mail klanten: [wie] Daniel (must), [locatie] overal (must), [wanneer] altijd (must) Kost wat tijd maar zo'n lijst maakt het uitzoeken veel makkelijker. [edit]Vergeet er bij te zetten dat je in het lijstje opneemt welke document / mail / software nodig is voor de taak.[/edit]

Ik ken die verhalen ook. Verbaasde me dan ook over dit resultaat en heb nog even Gegoogled. Blijkbaar krijg je alleen geen cookies (althans het beruchte tracking cookie) via de iframe plugin: Bron Als je bezoeker ingelogd is bij Facebook is hij / zij akkoord gegaan met hun voorwaarden dus ik neem aan dat het gebruik van deze plugin voldoet aan de cookie-wet.

Niet dus. Heb zojuist op een verse Windows installatie met een verse Firefox een paar pagina's bekeken met de Facebook plugin en ik krijg géén cookie van Facebook en ook geen cookies van de site zelf die gebruikt zou kunnen worden door / voor Facebook. Browser instellingen staan op het accepteren van cookies van derden en krijg op bepaalde sites wel cookies van scorecard en doubleclick.

Nog niet. Als Chappelin iets meer informatie prijs geeft over zichzelf / zijn bedrijf geeft mijn 'quick-ingeblikt-vlees-scan' misschien meer geur :D

Google heeft een patent op de toepassing van 'mouse tracking' voor het ranken van zoekresultaten (zo uit mijn hoofd, patent kan iets specifieker zijn, lang geleden dat ik er over gelezen) Dus het zal wel waarde hebben. Vraag is of je genoeg bezoekers hebt die daadwerkelijk iets zinnigs doen met hun muis. Heb zelf eens met de techniek gespeeld om op afstand mee te kunnen kijken met gebruikers van webapplicaties. Maar die gebruikten de muis net als ik; zoek je doel met je ogen en dan in één lijn met de muis naar dat doel. Dat soort directe akties meet je al met Analytics. En als het andere akties dan kliks zijn ('hoveren' over een element of een menu uitklappen) dan kun je die met 'Analytics event tracking' ook meten. Heb je dus geen pakket van $99 per maand voor nodig.

Bugno is nogal onduidelijk over prototypes vs. solide software: Voor prototypes: ben het helemaal met je (Wouter33) eens. Maar voor productiewaardige software zie mijn verbastering van de, in bijna alle gevallen toepasselijke,quote 'a little knowledge is a dangerous thing'. [edit]quote & referentie toegevoegd[/edit]

Tien jaar geleden bestond de techniek Ajax nog niet, net als integratie met diensten als Google Maps, Twitter, Facebook. Was javascript nog iets om te controleren of een formulier ingevuld was. Had nog (bijna) niemand gehoord van SQL-injection of cross site scripting. Etc etc etc. Als je nu een site wilt bouwen die voldoet aan de huidige standaarden dan is de berg iets hoger dan tien jaar terug.

Voor prototyping kun je kijken naar RAD (rapid application development) tools en visual programming languages. Heb dit soort tools lang geleden gebruikt en kon daarmee met maar een paar regels code werkende prototypes bouwen. Dat was voor Windows maar voor webapplicaties zijn ze er ongetwijfeld ook. Denk aan Yahoo pipes (vooral webdata verwerken) en Google app inventor (voor Android en inmiddels 'overgenomen' door het MIT) Op het forum van Tweakers vind je meer informatie over welke tools beschikbaar zijn. Ook je vraag komt daar geregeld voorbij. In het algemeen: ik zou er niet aan beginnen tenzij je of je het als werk wilt gaan doen of je basiskennis wilt hebben om met programmeurs te praten. Het kost, zoals gezegd, veel tijd om op niveau te komen. En eerder, zolang je genoeg kennis hebt om gevaarlijke code te schrijven, moet je niets live zetten ;)

Nee, je certificaat is gekoppeld aan je domeinnaam niet aan het ip-adres. Dat je niet meerdere domeinnamen met SSL op één ip-adres kunt gebruiken is een limitering van SSL. (je kunt certificaten ook op je ip-adres zetten, dan zou je wel nieuwe certificaten moeten kopen, maar denk niet dat dat je bedoeling is)

Dit klopt niet en snap je verwarring. IP adressen kosten geld (en ip v4 adressen zijn schaars) daarom bieden, met name de goedkopere hostingpartijen, standaard geen eigen ip-adres per website aan. Een eigen ip-adres is een eis voor een SSL-certificaat en dus moet je bij die partijen eerst een ip-adres 'kopen' voor je SSL kunt gebruiken. De server heeft uiteraard wel een vast ip-adres maar meerdere sites delen dat adres.

Bij de standaard shared hosting van je provider staat dat ssl een optie is. Zoals gezegd is dat zo'n beetje de standaard. Het standaard aanbieden van SSL inclusief certificaat is helemaal niet handig. Er zijn namelijk veel verschillende typen SSL-certificaten die varieren in prijs van zeg 20 euro tot 100 euro. Daarnaast hoort een provider meer resources (met name cpu, of speciale hardwarematige ondersteuning) te reserveren op een server met sites die SSL gebruiken. Niet handig als slechts een fractie van de sites er gebruik van maakt. De enige variant die ik ooit gezien heb waar je kant & klare SSL, dus inclusief een certificaat, op je site hebt is met een url van de provider. Dus iets als https://ssl.provider.nl/mijn_domein_naam/ Voor beveiligde backend toepassingen voldoende maar ziet er wat vreemd uit voor je klanten. Maar als SSL het enige punt is dat je mist kun je toch een pakketselectie doen en voor de top tien even checken wat SSL kost? Kan nooit veel langer duren dan de tijd die je nu besteed hebt aan het typen van deze vraag ;)

En dan kun je altijd nog je bezoeker verleiden met cookies te accepteren en de volledige social media dingen laten zien.

Zonne-energie heeft inderdaad een theoretische limiet. Aan de ene kant door de hoeveel energie die zonlicht geeft, inderdaad ca 1000 watt per m2, aan de andere kant door de efficientie van het omzetten naar stroom (Shockley Queisser limiet) Maar Ad verbastert de wet van Moore een beetje door prijs mee te nemen en stelt dat het aantal kWh per geinvesteerde euro verdubbeld per 18 maanden (dus niet de opbrengst per m2) En dan kun je nog wel even vooruit :)

Te zien aan de plugin waar Frank naar linkt ligt het in dit geval wel aan de software en gaat een grote zware server niet erg helpen. Uit de inhoud van die plugin maak ik op dat de tabellen van opencart geen goede inhoudsopgave hebben. Wat mysql dan gaat doen is de hele database doorspitten naar de goede informatie. Vergelijk het met een dik kookboek zonder inhoudsopgave. Je moet het hele boek doorbladeren om het juiste recept te vinden. Met een inhoudsopgave alleen een paar pagina's. Mysql doet precies hetzelfde, als je zorgt voor een inhoudsopgave ('index') dan gaat alles rap, zonder leest mysql alles maar in en gaat alles langslopen. Het effect hiervan kan dramatisch zijn, zeker bij wat grotere lijsten informatie. Ben situaties tegengekomen waar een opdracht vijf seconden duurde zonder index en een tiende seconde met een index. Zou dus die plugin eens uitproberen :)

Ik heb de laadtijd van je site even bekeken met Firebug. De laadtijd van de pagina zelf (dus zonder plaatjes e.d.) duurt het langst. Daarbij is het 99% wachttijd. Dat wil, in de meeste gevallen, zeggen dat de server zelf inderdaad 'traag' is. Even Googlen op 'trage opencart site' levert dit draadje op stackoverflow op. Oorzaak die ze daar noemen is de berekening van het aantal producten in de categorieoverzichten. Klinkt plausibel omdat iedere pagina ongeveer even lang duurt en die telling van producten per categorie redelijk 'complex' is. Op het OpenCart forum staan instructies hoe je deze uitzet. Hoewel je site met één seconde voor de pagina en een totale laadtijd van 1,5-3 seconden naar mijn smaak niet erg traag is. [edit]Zie dat de link van Frank wijst naar een plugin die de tellingen bij de categorieen uitzet :)[/edit] [edit 2]Bij diezelfde plugin zit een SQL bestand om je database sneller te maken. Treurig dat dat nodig is (zou standaard in opencart moeten zitten) maar zo te zien gaat dat je siite inderdaad een stuk sneller maken.[/edit]

Oops, nou reageer ik toch weer ;) Je lijkt voornamelijk te reageren op berichten die passen in jouw visie op de zaak. Kun je je hele dossier (geanonimiseerd uiteraard) hier eens posten?

De wet schrijft in de meeste gevallen een redelijke termijn voor. Om te bepalen wat 'redelijk' is moet je naar de rechter. Gezien je houding (zonder details over het voortraject) ga ik niet meer reageren. Succes.

MIsschien denk ik wat te groot voor de situatie van de TS maar een koppeling naar bijvoorbeeld Exact of SAP kun je niet achterwege laten bij een integratietest. En ook voor 'kleinere' systemen kan al het verschil tussen bijvoorbeeld PHP 5.3 en PHP 5.4 de nodige problemen opleveren. Lastig punt voor zowel leverancier als afnemer natuurlijk. En meestal zijn de problemen ook vrij eenvoudig op te lossen. Maar het blijft prettig als je afspraken hebt over hoe en met welke software je ontwikkelt en test.