ceil() en round() ronden af, als het puur om weergave gaat waarbij de oorspronkelijke waarde niet aangepast wordt, dan lijkt mij http://php.net/number_format een beter alternatief.
Posts by FangorN
-
-
Er zijn legio manieren om dit in te richten maar als dit een puur informatieve (en dus redelijk statische?) website betreft, waarom schrijf je dit niet gewoon uit? 5 pagina's x 4 talen = 20 pagina's?
Ik denk wel dat het belangrijk is dat eenzelfde pagina in een andere taal ook echt als aparte pagina wordt gepresenteerd (dus ook met een unieke URL), omdat in zekere zin de content van een specifieke "pagina" in uiteenlopende talen echt anders is, m.a.w. deze zou ik niet op één hoop gooien.
Ik begrijp niet helemaal wat je probeert te bereiken met een sessie? Een sessie duurt doorgaans maar één bezoek. Als je dan toch een taalkeuze wilt onthouden over meerdere bezoeken dan lijkt mij een cookie geschikter?
Wat mij ook handig lijkt is dat je de opbouw in verschillende talen op eenzelfde wijze laat verlopen. Dus als je een soort colofon pagina hebt, dan zou de nederlandse variant bijvoorbeeld /nl/over-ons zijn, en de engelse variant /en/about-us ofzo. Hierbij helpt het natuurlijk ook dat je zoekmachinevriendelijke URL's gebruikt.
Ook zouden deze documenten taal-indicaties moeten hebben middels (op zijn minst) het lang-attribuut in de <html> tag. En zo zijn er nog wel meer optimalisaties mogelijk.
Vergis je niet, dit meertaligheidsgedoe is enorm breed en staat bekend als (of beter gezegd, maakt onderdeel uit van) "internationalisation" of "i18n". Dit is een wetenschap op zich. Hier valt ontzettend veel over te vinden.
Als je bijvoorbeeld Googled op "html same content different language" dan vind je al best wat info, zoals deze blog. Wellicht wat gedateerd, maar nog steeds redelijk relevant.
-
Uhm.
Heb je allereerst misschien nog wat terugkoppeling op jouw andere topic? Want nu komt het een beetje over alsof dit een bodemloze emmer is waar je maar info instort zonder dat er ooit iets terugkomt.
Dan, een witte pagina? Kijk eens naar je errorlogs, en/of zet het melden + weergeven van fouten aan door de volgende passage toe te voegen aan het begin van je code:
PHP<?php error_reporting(E_ALL); // welke fouten je wilt tonen (alles) ini_set('display_errors', 'stdout'); // waar je deze fouten wilt tonen (op het scherm) ?>Dit hoort uiteraard niet in productie-code thuis maar is alleen bedoeld voor ontwikkeling.
En tot slot, PHP heeft een uitgebreide documentatiesite: php.net.
Een goede manier om PHP te leren is het leren lezen van foutmeldingen zodat je deze (zelf) kunt debuggen, en php.net gebruikt als naslagwerk zodat je leert hoe dingen werken en wat er zoal out-of-the-box beschikbaar is.
Op php.net kun je onder andere lezen dat mysqli_result een klasse is. Je kunt niet bepaald simpelweg overal een "i" toevoegen en dan verwachten dat alles werkt als voorheen. Persoonlijk zou ik een fetch-variant gebruiken, of wellicht beter, een soort van wrapper schrijven voor je database-oplossing, en dan wellicht een methode implementeren die een enkele kolomwaarde ophaalt (een methode genaamd fetchValue() ofzo?).
PS: MySQLi werkt met objecten, daarom is het wellicht verstandig om jezelf de object georiënteerde schrijfwijze aan te leren. Daarnaast heeft MySQLi ook zelf voorzieningen voor exceptions.
-
Ik kijk in mijn glazen bol... en deze is troebel :).
De melding "Unknown column 'activatie' in 'field list'" zou je toch een eind in de goede richting moeten sturen.
Gebruik je een pakket? Zelf gerolde code? Ergens moet ofwel code ofwel de database gebruik maken van deze exacte kolom(naam), anders zou je deze fout niet krijgen?
Zoals je zelf aangeeft: deze fout treedt op in de verwerkingsstap van de actie waarin je je e-mailadres wijzigt. Dat lijkt mij een goede startplaats om te zoeken dan.
-
Het begint inderdaad met het begrijpen wat SQL-injectie nu precies is.
Een query ziet er vaak als volgt uit (abstract):
Code[SQL][DATA][SQL][DATA]etc.Waarbij [SQL] gewone SQL is en [DATA] variabele data is die uit een externe bron komt ("van buiten de database"). Doordat de uiteindelijke query dynamisch van aard is waarbij de [DATA]-plaatsen min of meer als placeholders gebruikt worden stelt dit je ook in staat om dynamische content of zelfs complete webpagina's te genereren met de resultaten hiervan.
Het gedrag van zo'n query ligt vaak wel vast: deze heeft een zeker voorgeschreven werking. Indien dit soort dynamische queries niet goed beveiligd zijn kan men de werking van de query manipuleren. Dit is dan mogelijk doordat de [DATA]-delen als SQL geïnterpreteerd kunnen worden. Dit is normaal gesproken natuurlijk nooit de bedoeling, vaak wordt deze manipulatie-ruimte misbruikt om queries naar je hand te zetten en ofwel gevoelige informatie te stelen of rechtstreeks controles te omzeilen. Dit is wat SQL-injectie in feite is: het injecteren van DATA in een query die vervolgens als SQL geïnterpreteerd wordt.
Hoe voorkom je SQL-injectie? Dit doe je door de DATA te ontdoen van enige mogelijke speciale betekenis die deze DATA heeft binnen SQL. Concreet: door deze DATA te escapen. Er zijn verschillende manieren om dit te doen, dus het hangt er een beetje vanaf wat je gebruikt. MySQLi? PDO? Iets anders?
Iets wat wel belangrijk is is het volgende: escaping is gekoppeld aan character encoding. Of liever gezegd, voor een correcte werking van escaping is het zaak dat je character encoderingen in de pas lopen.
Daarnaast moet ook niet blindelings vertrouwd worden op enkel de escaping-functionaliteit. Deze functies escapen alleen bepaalde karakters, er wordt niets ge-escaped als er niets te escapen valt! Zo zou bijvoorbeeld het uitvoeren van een real_escape_string() functie of methode op het volgende stuk DATA geen enkel effect hebben:
CodeOR 1=1En daarmee is mogelijk een SQL-injectie geslaagd.
Als je dus enkel escaping-functionaliteit gebruikt en verder niets is dit dus vaak onvoldoende om SQL-injecties te voorkomen!
Eigenlijk dien je in andere (of liever gezegd ALLE) contexten precies hetzelfde te doen: in de HTML-context escape je ook (user) DATA met behulp van functies als htmlspecialchars() (en deze functie heeft ook een parameter voor een character encoding!) om ervoor te zorgen dat deze niet als HTML geïnterpreteerd wordt of als JavaScript die mogelijk uitgevoerd kan worden.
En dit alles valt eigenlijk weer onder het bredere motto Filter Input, Escape Output. Eigenlijk zou je bij elk stuk data wat uit een externe bron komt jezelf af moeten vragen of er een reden is om het niet te escapen, en dat anders gewoon altijd doen. Zelfs als (user) DATA is weggeschreven naar de database is data nog steeds niet veilig, omdat je niet altijd op voorhand kunt zeggen in welke context deze gebruikt gaat worden en wat er dan ge-escaped dient te worden.
Escaping-on-input (alles vantevoren onschadelijk maken door er bijvoorbeeld allerlei escaping-functionaliteit overheen te gooien voordat je dingen naar de database wegschrijft) is ook geen goede oplossing, omdat je dan mogelijk dingen op den duur moet un-escapen. Ook is het gewoon veel makkelijker om er vanuit te gaan dat iets niet ge-escaped is en dat dan altijd net voor gebruik (weergave op een pagina of gebruik in een query) te doen.
Dit zorgt gewoon voor een super consequente werkwijze waar de kans op fouten vrij klein is, mede door de continue realisatie dat je met onbetrouwbare (user) DATA bezig bent, en natuurlijke de rechtstreekse escaping op het moment dat dit nodig is, je kunt dit direct zien en je hoeft je dan dus ook niet af te vragen of dit ergens anders wellicht is gebeurd.
-
Mja, maar de methode ziet eruit alsof je een reeks items koopt of kunt kopen (mogelijk met verschillende hoeveelheden), ik vermoed dat enkel het eerste item in de lijst wordt aangeschaft met bovenstaande syntax omdat waarschijnlijk enkel het record dat betrekking heeft op de eerste CASE die voldoet wordt geupdate. En daarbij is er dus helemaal geen controle of er wel genoeg items zijn.
Ben je nagegaan dat als een speler meerdere items van een NPC koopt dat alle hoeveelheden (zowel van verkochte als aangekochte) van items na afloop kloppen?
En dan heb je nu dus nog het potentiële probleem van een gebrek aan concurrency. Voor het bijwerken van hoeveelheden die beheerd worden door en overgedragen worden tussen meerdere partijen dienen voor een goed verloop in bijna alle gevallen transacties ingezet te worden, waarbij de hoeveelheid eerst "gereserveerd" wordt zodat deze enkel kan overgedragen worden aan één andere partij. Dit zodat er niet, door een potentieel parallel verloop van meerdere queries, ineens hoeveelheden uit het niets gecreëerd worden of in het niets verdwijnen.
Is het niet handiger om dit net zoals bij een order op te splitsen in orderregels? Dan heb je meer controle over de gang van zaken. En mogelijk moet je ook rekening houden met het volgende: stel dat iemand zijn order heeft ingeklopt, maar iemand was hem net voor waardoor een of meer items niet meer in de gewenste hoeveelheid verkrijgbaar zijn. Wat gebeurt er dan? Wordt de hele order teruggedraaid, of gedeeltelijk doorgevoerd? Dit lijkt mij verwarrend, stel dat je o.a. 5 keer item A hebt gekocht en dat pas later blijkt dat item A niet beschikbaar was. Daarom lijkt mij dit reden te meer (ook qua eenvoud) om het gewoon niet mogelijk te maken om batches te kopen, maar slechts één item (in een bepaalde hoeveelheid) per keer.
-
Als ik het goed begrijp kun je meerdere items (in verschillende) hoeveelheden tegelijkertijd kopen? Maar zou je dan niet meerdere queries moeten gebruiken? Alleen het eerste WHEN THEN blok wat voldoet wordt dan toch maar uitgevoerd? En ook weet je dan niet precies welke items iemand ontvangt? Of ik moet niet goed begrijpen wat deze methode nu concreet doet?
En is de controle nu uberhaupt wel goed? Zou dat niet zoiets moeten zijn als WHEN $items[$i] AND available >= $quantity[$i], oftewel, er moeten minstens zoveel items op voorraad zijn om er zoveel af te nemen? Maar eigenlijk is deze hele constructie niet echt goed, want deze locked de resource niet, dus als meerdere mensen tegelijkertijd hetzelfde item willen kopen (zodanig dat je in totaliteit eigenlijk meer koopt dan er op voorraad is) dan gaat dat misschien nog lukken ook.
Zou je eens kunnen uitleggen wat sellNpcItems() nu precies zou moeten doen, en wat is de precieze betekenis van $items, $quantity en $npc_id? En zou je $items en $quantity niet kunnen combineren tot simpelweg een $quantity array, waarbij de index hiervan het item-id is?
-
Of een crossover, waarbij je andere mafiabazen intimideert.
-
@mugaru dit is mogelijk best een handige tool voor het werk wat het doet, maar lost andere (bijvoorbeeld de eerder genoemde) problemen niet op (denk aan algehele opbouw en werkwijze van pagina's / stukken code).
Daarnaast bega je in zekere zin dezelfde "fout" opnieuw: vanaf PHP 7 is de oorspronkelijke MySQL-driver verdwenen, en hiermee alle mysql_* functies. Het is logisch dat als je dan met dezelfde codebase verder wilt dat deze functies vervangen moeten worden. Maar wat doe je dan als je deze tool gebruikt? Je verandert daarmee alle instanties van mysql_* naar een mysqli_* variant, mogelijk met extra of verwisselde parameters.
Maar wat je hier wederom doet is hardcoding van de databaseoplossing. Dit zal natuurlijk altijd in zekere mate het geval zijn omdat en zolang je rechtstreeks (mogelijk database-specifieke) SQL in je code zet, en dus geen gebruik maakt van een Database Abstraction Layer (DAL). Toch valt er iets te zeggen om -op zijn minst- een Database Access Abstraction Layer (DAAL) te gebruiken. Want wie zegt dat er op den duur niet opnieuw dingen veranderen in MySQL-land?
Het voordeel hiervan is een -weliswaar gedeeltelijke- ontkoppeling van specifieke database-gerelateerde functies en methoden zodat wanneer (niet als maar wanneer :)) er iets wijzigt, je -in het ideale geval uiteraard- enkel de implementatie van deze code hoeft te veranderen, en verder inhoudelijk geen letter applicatiecode hoeft aan te passen.
Een ander voordeel is dat je dingen kunt vereenvoudigen en opdrachten kunt bundelen zodat je gemakkelijker kunt werken met de desbetreffende database. Dit bespaart je dus op den duur ook tijd.
Wat ik in wezen voorstel is dat je, en eigenlijk iedereen die van plan is om met MySQL te werken, er verstandig aan doet om een soort van wrapper om je database-interactie te schrijven (maar misschien nog beter is een DAL uiteraard, omdat je daarmee dit helemaal loskoppelt van het gebruik. Dit is wel een tradeoff, het introduceert overhead, abstractie en complexiteit, en de vraag is of het dat waard is).
Als je uitsluitend MySQL gebruikt is MySQLi eigenlijk de beste driver, omdat PDO niet geschreven is voor MySQL, daarvoor is de PDO_MYSQL driver, en daar zit een aanzienlijke brok configuratie die je goed onder de knie moet hebben voor foutvrije operatie. De vraag is ook, wanneer je PDO gebruikt, of je deze abstractie ooit echt nodig hebt. Als je nooit van plan bent om te schakelen van database in een applicatie (ik heb hier eigenlijk nog nooit van gehoord in applicaties) dan kun je net zo goed MySQLi gebruiken omdat deze expliciet is geschreven en geoptimaliseerd voor gebruik van MySQL.
Deze wrapper dient uiteraard niet triviaal te zijn, simpelweg een soort van MyDB class bakken waarbij je vervolgens direct met een mysqli-object kunt werken is te kort door de bocht - dit stuk code moet echt werk uit handen nemen en daardoor een zekere meerwaarde creëren. Met dus als bijkomend voordeel dat je de omgang met je MySQL-database in afzondering van de rest van je code kunt behandelen.
Het belangrijkste hier is eigenlijk dat je hardcoding (zoveel mogelijk) voorkomt en niet in herhaling treedt met wat in wezen al eerder misging.
-
Komt het niet bij je op dat je beter kan aangeven wat er mis mee is in fatsoenlijk geschreven tekst?
Tot op zekere hoogte. Maar kijk eens naar het codefragment op de eerste pagina. Serieus, wtf is dit? Ik denk dat het mij minder tijd kost om iets nieuws te schrijven dan om uit te leggen wat hier allemaal aan mankeert.
Er zijn situaties waarin nog recht te buigen valt wat krom is, en in sommige situaties is het gewoon beter om hier niet meer aan te beginnen. Dit project lijkt mij toch een beetje een gevalletje uit de laatstgenoemde categorie.
Neemt niet weg dat dit een leerzame (doch redelijk nutteloze) exercitie kan zijn, maar daarbij moet je je wel goed realiseren dat ondanks het feit dat straks alles mogelijk "werkt" als je alles hebt omgeschreven naar de moderne uitvoering van verouderde functies en/of constructies, dat de algehele structuur van dit ding waarschijnlijk een complete incoherente gribus was, is en blijft.
Je helpt hem totaal niet, je kraakt alles wat hij doet/probeert af en zegt "gooi in de prullenbak" .
Dit zou ook mijn advies zijn. Van slechte code leer je meestal alleen hoe iets niet moet. Het hangt er ook maar net vanaf hoe je denkt een vragensteller te "helpen". Op het moment dat je een antwoord geeft heb je ook een zekere verantwoordelijkheid om te adviseren en niet alleen maar het kortste pad te tonen wat naar een directe oplossing voor het directe probleem leidt. Dat laatste is meestal wat gebeurt op forums. En daarmee help je mensen op weg op een verkeerd pad.
Stel dat jij een huizenbeheerder bent en je staat op het punt om een of andere bouwval van de hand te doen. Zou je dan mensen adviseren om de muren maar een keer over te sauzen om het wat beter te laten ogen, of zou je ze toch beter kunnen adviseren om het pand maar om te trekken omdat er eigenlijk een direct en permanent instortingsgevaar dreigt?
-
Dat hebben ze nu maar dat word weer handmatig omgezet in excel.
Mja dan is het misschien inderdaad handig dat dit rechtstreeks in een database geslingerd wordt. Scheelt een hoop boekhouding.
Maar je zou hier dus een webapplicatie van kunnen maken, als je dat nog niet overwogen had.
Maar waarom zou integratie in een bestaand pakket of een bestaand pakket geen optie zijn (zoals dat Magister)? Dat is mogelijk handiger dan extra automatiseringseilandjes te creëren. Wat ontbreekt er in die pakketten om het te laten werken?
-
@cakemasher ik denk dat topicstarter bedoelt dat een docent een Roll Call kan doen om te zien wie aanwezig is. Maar ja, je zult dan wel een database moeten vullen met leerlingen, klassen, docenten, roosters (dus ook vakken en lesuren) et cetera.
Het is niet helemaal een simpel CRUD systeem, want uiteindelijk wil je ook wat met deze absentie-informatie doen, zoals het maken van rapportages enzo. Dit laatste bepaalt ook hoe je applicatie opgezet zou moeten worden, dit is -mede- afhankelijk van de vragen die je beantwoord wilt zien met dit systeem.
Het registreren van presentie/absentie zal slechts een klein onderdeel van het hele systeem zijn.
-
Je zou wat JSON data uit de Graph API kunnen trekken als het geen layout-optie van de button zelf is misschien. Maar dan ben je meer in de richting van een custom button aan het werken.
-
Vroegah hadden wij hier gewoon een klassenboek voor, is dat niet de simpelste oplossing?
-
Zie mijn PM-berichten.
-
Klopt het dat iedereen als user 1 in kan loggen?
Zo niet, dan zou ik toch eens gaan zorgen dat je queries niet vatbaar zijn voor SQL-injectie.
Deze heeft wel lekker veel callcredits (24.998), wat dat ook moge zijn.
En het uitloggen lijkt nog niet te werken?
-
Hoogstwaarschijnlijk oververhitting.
Het oppervlak waarop je de laptop plaatst, hoe warm de ruimte is waarin deze zich bevindt en/of hoe goed de luchtcirculatie is kunnen van invloed zijn op het al dan niet vastlopen. (En ook hoeveel stof in de ruimte circuleert, is dit bijvoorbeeld toevallig ook je slaapkamer?)
Ook af en toe de luchttoevoerkanalen en fans schoonmaken (als stof de boel verstopt kan het hard gaan) kan natuurlijk helpen.
EDIT: en ja, kan dus ook een hardwarematig mankement zijn.
-
Niet alleen doen, maar ook begrijpen wat je doet. Eerst wat theoretische kennis opdoen van HTML (en wellicht HTTP en hoe websites in het algemeen werken), CSS en JavaScript kan ook geen kwaad, voordat je de sprong in het diepe waagt met PHP. Ik neem tenminste aan dat het om PHP gaat? Of welke programmeertaal bedoel je?
Het kiezen van een (onderzoeks)onderwerp kan hier ook bij helpen, je hebt dan in ieder geval een concreet doel. En zoals @Luc aangeeft kan het helpen om eenvoudig te beginnen... of iets op te splitsen in deelproblemen.
Iets wat ik heel vaak mis bij dit leren van een programmeertaal (specifiek PHP) is het omgaan met fout(melding)en. Er wordt eigenlijk alleen maar ingezet op hoe het wel moet, en niet zozeer wat je moet doen als er iets misgaat. Je leert in wezen een wijsje opzeggen en als je om wat voor reden dan ook van de gebaande paden afraakt (punt, komma of accolade vergeten) is men compleet verloren. En dat terwijl PHP toch hele duidelijke en begrijpelijke foutmeldingen heeft. Deze leren lezen en hierop acteren verschaft je enorm veel inzicht en ook een stuk meer zelfredzaamheid.
En dan is er een hele hoop informatie te vinden, onder andere op YouTube. Maar ook een hele hoop slechte informatie. Het meest verraderlijke zijn tutorials die ogenschijnlijk niet slecht zijn, maar op sommige vlakken echt de plank misslaan. Of websites zoals w3schools, daarin zit af en toe ook een hoop bagger. Voor het ongetrainde oog is het heel moeilijk om dit onderscheid in eerste instantie te kunnen maken, maar aan de andere kant je zult toch ergens moeten beginnen.
Het meest belangrijke is niet zozeer wat je programmeert en hoe, maar waarom. Als je namelijk niet kunt motiveren waarom je iets op een bepaalde manier hebt aangepakt, dan heb je er dus ook niet over nagedacht en/of begrijp je zelf niet volledig wat je aan het doen bent.
-
Dat Burger King filmpje is natuurlijk absurd met een zekere kern van waarheid. Weet ook niet (of hoop ook niet) dat de personen daarin een soort doorsnee van de amerikaanse samenleving voorstellen, die overwegend nogal primair reageren en bijna schuimbekkend aan de toonbank staan als ze niet terstond hun Whopper in ontvangst mogen nemen.
Wat vooral, of in het algemeen, heel gevaarlijk is is de verspreiding van misinformatie / disinformatie - verkeerde informatie die per ongeluk of expres wordt verspreid. Daarbij helpt het al helemaal niet als (semi) populaire (internet) opiniemakers allerlei half of niet kloppende informatie de wereld inslingeren. Niets is zo moeilijk om gevestigde misverstanden de wereld uit te helpen, maar het wordt geprobeerd:
External Content www.youtube.comContent embedded from external sources will not be displayed without your consent.Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.And a follow up (nog hilarischer dan de eerste lol):
External Content www.youtube.comContent embedded from external sources will not be displayed without your consent.Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.In een van de comments wordt denk ik goed samengevat wat er daadwerkelijk gaande is:
CitaatThe internet is considered a utility because it is funded by the public and is considered a public service, so ISPs are currently regulated as utility providers in nearly every major country. The FCC is trying to reclassify net neutrality from Title II (common courier) to Title I (information service), which means internet service will be regulated the same way cable service is.
Bovenstaand filmpje (de eerste) is beter in de zin dat het duidelijk(er) uitlegd wat net neutraliteit inhoudt, en waarom het een goede zaak is (en hoeveel poep Ben Shapiro uitkraamt). Het is minder goed in die zin dat de discussie -zoals daar of ergens anders in de YouTube comments wordt opgemerkt- alweer verplaatst is van ideeën naar (wat) personen (gezegd hebben of zouden hebben gezegd). Daarmee beweeg je in feite alweer weg waar het in wezen over zou moeten gaan.In bovenstaande YouTube clip wordt ook weer gelinkt naar een andere clip:
External Content www.youtube.comContent embedded from external sources will not be displayed without your consent.Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.Deze persoon heeft verstand van zaken en zegt ook verstandige dingen. Het is alweer een tijdje geleden dat ik deze gezien heb maar volgens mij was de strekking dat het absurd is dat je pakketjes informatie gaat beoordelen op inhoud, en er op die manier een prijs (en serveersnelheid) aan koppelt. Ook in hoeverre dat technisch haalbaar is. En daarnaast, als deze idioterie doorzet in de VS, wat voor precedent dit schept voor andere wereldmachten / conglomeraten die mogelijk ook op deze manier een vinger in de pap willen. En dan is er nog de amerikaanse consument: deze heeft haast geen keuze meer wat er dan aangeboden gaat worden (of tegen welke prijs of snelheid) omdat de beschikbare ISP (enkelvoud) of ISPs (meervoud) vaak rechtstreeks gekoppeld zijn aan de geografische locatie. Zou je een andere informatie-aanbod willen zou je fysiek moeten verhuizen.
Los van dit alles: dit is een complex onderwerp. Als je hierover een mening wilt vormen zul je wat informatie moeten verzamelen (bij voorkeur uit meerdere bronnen) en ook moeten onderzoeken of wat er wordt gezegd ook echt klopt. Dit kun je waarschijnlijk niet makkelijk vatten in één YouTube filmpje, deze bevatten vaak ook maar één aspect of één standpunt.
Het tragische is dat zowel de Democraten als de Republikeinen deze nieuwe voorstellen niets vinden, maar dat het er misschien toch uitziet dat deze er doorgedrukt gaan worden (weet niet of er al een uitspraak over was?). Dit zou een verliesbeurt betekenen voor de politiek en de burger - de enige die er beter van wordt zijn waarschijnlijk de eigenaren van de netwerken.
EDIT: en ook: het internet is een dienst die verstrekt wordt, en zou moeten worden, zonder limitaties. De verleners van deze dienst zouden zich op geen enkele wijze moeten bemoeien met de wijze waarop dit medium wordt gebruikt, dit is aan de gebruikers. EDIT #2: en dat is dus wat nu getracht wordt om zeep te helpen: de classificatie hiervan (zie quote). Daarmee verliezen consumenten waarschijnlijk rechten, en het Internet een groot deel van haar "vrijheid".
-
Het maken van afbeeldingen lijkt al mogelijk - er is een uploaddienst. Mogelijk kun je de hyperlink van zo'n afbeelding op een of andere manier koppelen aan een twitter bericht, maar de vraag is in hoeverre je dit proces kunt automatiseren wat waarschijnlijk je doel is?
Aangezien dit een technisch inhoudelijke vraag is en je dit het beste binnen de gebruikte applicatie af kunt handelen zonder extra toeters en bellen... Vraag het aan SierraChart of dit mogelijk is (op het support forum of via een contact e-mail), of stel het voor als een feature request.
