Dat is wel mooi.quote:Op maandag 23 maart 2015 06:26 schreef totalvamp het volgende:
http://www.phpclasses.org(...)inally-Approved.html
EINDELIJK!
quote:Op maandag 23 maart 2015 14:37 schreef bondage het volgende:
Hier nog mensen belang bij een leuke functie als database opschoon mannetje?
https://www.starapple.nl/vacatures/58-sql-dba/
_
quote:Aanbod
3500 met niets bijzonders
quote:Op maandag 23 maart 2015 14:37 schreef bondage het volgende:
Hier nog mensen belang bij een leuke functie als database opschoon mannetje?
https://www.starapple.nl/vacatures/58-sql-dba/
_
Die viel mij ook op ja.quote:
Dit is inderdaad een voorbeeld van hoe je het absoluut niet moet doen. Leuk aanbod maar ik laat het liever aan me voorbij gaanquote:Op maandag 23 maart 2015 16:37 schreef Monolith het volgende:
[..]
Die viel mij ook op ja.
Zo trek je ook geen mensen natuurlijk. Zet er dan iets neer in de trant van '3500 euro, een zak beukenootjes en een eekhoorn' of iets dergelijks. Dat zou wel bijzonder zijn.
beter dan de eeuwige zoektocht naar een ondernemende teamplayer die van aanpakken weet.quote:Op maandag 23 maart 2015 16:41 schreef bondage het volgende:
[..]
Dit is inderdaad een voorbeeld van hoe je het absoluut niet moet doen. Leuk aanbod maar ik laat het liever aan me voorbij gaan
Zie jij dat vaak in vacatures? Ik zie toch voornamelijk zwaar op de inhoud gerichte vacatures voorbij komen.quote:Op maandag 23 maart 2015 21:39 schreef n8n het volgende:
[..]
beter dan de eeuwige zoektocht naar een ondernemende teamplayer die van aanpakken weet.
Nog niet geprobeerd nee, maar ik hou gewoon de RFC's in de gatenquote:Op zondag 22 maart 2015 22:30 schreef Robuustheid het volgende:
Yep, maar ik ga wel vanuit dat TwenteFC niet daar al mee loopt te klooien. Want dat PHP 7 is nog vrij buggy en vooral voorbehouden aan ontwikkelaars die contributies doen aan de PHP community.
Ik lees ze eigenlijk vrijwel nooit, het zijn wel de vervelende pro-actieve teksten die negatief opvallen (geschreven door zo’n ‘vlotte’ marketing-asshole).quote:Op maandag 23 maart 2015 21:51 schreef Monolith het volgende:
[..]
Zie jij dat vaak in vacatures? Ik zie toch voornamelijk zwaar op de inhoud gerichte vacatures voorbij komen.
Ik sta op de mailinglist van een aantal recruiters en daarnaast word ik sowieso wel vaak benaderd via LinkedIn en het zijn in ieder geval altijd vacatures die naast de primaire arbeidsvoorwaarden voornamelijk benadrukken dat er uitstekende opleidingsbudgetten zijn, met welke cutting-edge technologieën wordt gewerkt, enzovoort. Zelfs in de HR zijn ze niet helemaal achterlijk en weten ze wel dat ze de vacatures moeten aanpassen op hun doelpubliek. Dat de recruiters vaak zelf niet snappen dat bepaalde technologieën mijlenver uit elkaar liggen is natuurlijk een ander verhaal.quote:Op maandag 23 maart 2015 23:03 schreef n8n het volgende:
[..]
Ik lees ze eigenlijk vrijwel nooit, het zijn wel de vervelende pro-actieve teksten die negatief opvallen (geschreven door zo’n ‘vlotte’ marketing-asshole).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | <?php class Item<T> { protected $item; public function __construct(T $item = null) { $this->item = $item; } public function getItem() { return $item; } public function setItem(T $item) { $this->item = $item; } } class Test { public function runTest() { $item = new Item<StdClass>; var_dump($item instanceof Item); // true $item->setItem(new StdClass); // works fine // $item->setItem([]); // E_RECOVERABLE_ERROR } } ?> |
1 2 3 4 5 6 7 8 9 10 11 | RewriteEngine On php_flag display_startup_errors on php_flag display_errors on php_flag html_errors on php_flag log_errors on RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php?querystring=$1 [L] |
Kijk eens in de network tab van firebug/developer tools, misschien zit er in je html een tag met een verkeerde of lege href/src die naar de index.php wordt doorgestuurd.quote:Op dinsdag 31 maart 2015 15:39 schreef boskameel het volgende:
Ik weet niet of dit hier hoort, maar kent iemand het probleem dat bij url rewrites 2 keer de regel wordt uitgevoerd?
Mijn htaccess ziet er zo uit:
[ code verwijderd ]
als ik bv naar http://mijndomein/blabla/ ga, dan wordt het index.php 2 keer opgeroepen. Zit er gewoon een foutje in, of is dit standaard?
[edit]
Ik zie dat het probleem zich alleen voordoet in firefox en ie Dit is toch serverside?
[/edit]
Is het niet je browser die een request doet naar je favicon.ico?quote:Op dinsdag 31 maart 2015 16:14 schreef boskameel het volgende:
Thanks, ik zie het, het is de base href. Maar die heb ik nodig, anders zal ik alles moeten omzetten naar absolute paden.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | <?php $expiretime=10080; //expire time in minutes, 7 days = 7*24*60 $tmpFolder="pictures/"; $fileTypes="*.*"; foreach (glob($tmpFolder . $fileTypes) as $Filename) { // Read file creation time $FileCreationTime = filectime($Filename); // Calculate file age in seconds $FileAge = time() - $FileCreationTime; // Is the file older than the given time span? if ($FileAge > ($expiretime * 60)){ // Now do something with the olders files... echo "The file $Filename is older than $expiretime minutes\n"; //delete files: unlink($Filename); } } ?> |
Krijg je helemaal geen output? Alleen jpg verwijderen zou je hiermee moeten kunnen doen: $fileTypes="*.*"; veranderen in $fileTypes="*.jpg";quote:Op zondag 5 april 2015 17:36 schreef davedavy het volgende:
Een vraagje, ik ben zelf de PHP taal niet machtig maar met Google kom je al een heel eind. Laatst heb ik een leuk scriptje gevonden dat netjes in mijn map waar ik beveiligingscamera foto's opsla de foto's ouder dan 7 dagen verwijderde. Nu is mijn website leuk gecrasht en ben ik alles kwijt
Met als gevolg, ik moet opnieuw .jpg's automatisch verwijderd krijgen die ouder zijn dan 7 dagen. Puur jpg's, anders verwijderd die alles eromheen ook
Ik heb zelf dit gevonden:
[ code verwijderd ]
https://naiboo.wordpress.(...)ys-or-10080-minutes/
Maar die doet niks Wat doe ik fout?
Uiteraard heb ik $fileTypes="*.*" al veranderd naar $fileTypes="*.jpg" maar ik krijg totaal geen output, de jpg bestandjes staan er nog leuk in. En ze zijn ook ouder dan de aangegeven tijd.quote:Op zondag 5 april 2015 17:43 schreef bondage het volgende:
[..]
Krijg je helemaal geen output? Alleen jpg verwijderen zou je hiermee moeten kunnen doen: $fileTypes="*.*"; veranderen in $fileTypes="*.jpg";
Beiden ja, ik heb atm de tijd op slechts 1 minuut staan en hij verwijderd nog steeds niets Er is trouwens wel een error maar dat lijkt me er niks mee te doen hebben:quote:Op zondag 5 april 2015 17:58 schreef TwenteFC het volgende:
Heb je wel de foutmeldingen aan staan? En zijn er uberhaupt .jpg afbeeldingen die ouder dan 7 dagen zijn?
1 | [05-Apr-2015 10:58:54 CST6CDT] PHP Warning: Module 'sqlite' already loaded in Unknown on line 0 |
Ik vermoed dan inderdaad dat je niet in de juiste folder aan het kijken bent, var_dump dit eens : (glob($tmpFolder . $fileTypes)quote:Op zondag 5 april 2015 18:01 schreef davedavy het volgende:
[..]
Beiden ja, ik heb atm de tijd op slechts 1 minuut staan en hij verwijderd nog steeds niets Er is trouwens wel een error maar dat lijkt me er niks mee te doen hebben:
[ code verwijderd ]
De tijd klopt niet, weer een fout van me crappy host. Net als deze error neem ik aan.
"$tmpFolder="pictures/"; " moet leiden naar de map waar de jpg files zitten neem ik aan? Wellicht dat ik daar naar de foute map zit te leiden oid. Ik moet het absolut path hebben toch?
1 | /home/dave/public_html/test |
Omdat het een shared hosting pakket is. Ik kan er wel cron jobs uitvoeren maar kreeg het niet voor mekaar enkel JPG's te verwijderen.quote:Op maandag 6 april 2015 09:43 schreef KomtTijd... het volgende:
Waarom doe je niet gewoon
[ code verwijderd ]
Vrij zeker dat het via Google moetquote:Op dinsdag 7 april 2015 18:10 schreef Tijn het volgende:
Weet iemand of YouTube een API heeft om in te loggen vanaf je eigen website? Of moet je dan Google Sign-In gebruiken?
Ja, daar ben ik ook bang voor. Het probleem is alleen dat ik alleen geïnteresseerd ben in gebruikers van YouTube.quote:
Ja, ik had ook nog wat anders gevonden. Ik denk dat het hiermee wel moet lukken, maar ik hoopte op een hapklaardere brok.quote:Op dinsdag 7 april 2015 18:42 schreef KomtTijd... het volgende:
https://developers.google(...)esources/Google-APIs
Dit gelezen?
Denk persoonlijk dat je van ingelogde gebruikers wel toegang kunt vragen tot hun channels, en dan aan de hand daarvan kunt bepalen of je de login wel of niet accepteert?
1 2 3 4 | # 2015-04-09 10:00 UTC = 2015-04-09 12:00 CET SELECT UNIX_TIMESTAMP( CONVERT_TZ('2015-04-09 10:00:00', '+00:00', @@session.time_zone) ); |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | CREATE TABLE Trans ( CheckinTime INTEGER, CheckoutTime INTEGER, PricePaid INTEGER, CarryID INTEGER, CheckinLoc INTEGER, CheckoutLoc INTEGER, PRIMARY KEY(CheckinTime), FOREIGN KEY(CarryID) REFERENCES OVchipcard(CardID) ); CREATE TABLE OVchipcard ( CardID INTEGER PRIMARY KEY, balance INTEGER, RegistrationDate INTEGER, owns INTEGER, FOREIGN KEY(owns) REFERENCES Passenger(name) ); |
Error Code: 1005. Can't create table 'test.trans' (errno: 150)quote:Op vrijdag 10 april 2015 22:58 schreef Rockfire het volgende:
Wat gaat er precies fout? Ik kan me zo voorstellen dat het aanmaken van de eerste tabel fout gaat, omdat de foreign key niet gemaakt kan worden omdat de tabel waar hij naar wijst nog niet bestaat.
Heb je het al geprobeerd door eerst de tabellen aan te maken en pas daarna de foreign key constraints?quote:Op vrijdag 10 april 2015 23:07 schreef Nattekat het volgende:
[..]
Error Code: 1005. Can't create table 'test.trans' (errno: 150)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | CREATE TABLE Trans ( CheckinTime INTEGER, CheckoutTime INTEGER, PricePaid INTEGER, CarryID INTEGER, CheckinLoc INTEGER, CheckoutLoc INTEGER, PRIMARY KEY(CheckinTime) ); CREATE TABLE OVchipcard ( CardID INTEGER PRIMARY KEY, balance INTEGER, RegistrationDate INTEGER, owns INTEGER ); ... ALTER TABLE Trans ADD CONSTRAINT fk_CarryID FOREIGN KEY (CarryId) REFERENCES OVchipcard(CardID); ALTER TABLE OVchipcard ADD CONSTRAINT fk_owns FOREIGN KEY (owns) REFERENCES Passenger(name); |
Dat deed 't hemquote:Op zaterdag 11 april 2015 20:19 schreef Rockfire het volgende:
[..]
Heb je het al geprobeerd door eerst de tabellen aan te maken en pas daarna de foreign key constraints?
[ code verwijderd ]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | mysql> CREATE TABLE employees (data JSON); Query OK, 0 rows affected (0,01 sec) mysql> INSERT INTO employees VALUES ('{"id": 1, "name": "Jane"}'); Query OK, 1 row affected (0,00 sec) mysql> INSERT INTO employees VALUES ('{"id": 2, "name": "Joe"}'); Query OK, 1 row affected (0,00 sec) mysql> select * from employees; +---------------------------+ | data | +---------------------------+ | {"id": 1, "name": "Jane"} | | {"id": 2, "name": "Joe"} | +---------------------------+ 2 rows in set (0,00 sec) mysql> select jsn_extract(data, '$.name') from employees; +-----------------------------+ | jsn_extract(data, '$.name') | +-----------------------------+ | "Jane" | | "Joe" | +-----------------------------+ 2 rows in set (0,00 sec) |
Heb ik ook eens gedaan.quote:Op maandag 13 april 2015 12:05 schreef Tijn het volgende:
Ha, dat is best cool. Ik sla sowieso vrij vaak JSON op in MySQL voor applicatie-specifieke data waar verder niet op geselecteerd of gesorteerd hoeft te worden.
Dat voor simpele configs dus en native JSON NoSql databases voor daadwerkelijke data.quote:Op maandag 13 april 2015 17:05 schreef raptorix het volgende:
Mwoah ik zou dat toch eerder in een config bestand zetten, vooral als er omgevings specifieke waarden in staan.
Het grote voordeel is dan ook dat je dat soort zaken eenvoudig mee kunt nemen in je auto deploys, hier doen we dat per omgeving specifiek met XML transformations.quote:Op maandag 13 april 2015 17:11 schreef Monolith het volgende:
[..]
Dat voor simpele configs dus en native JSON NoSql databases voor daadwerkelijke data.
Er zijn uitzonderingen waarbij het toch wel handig is om te doen. Ik had een keer een database, waarbij er informatie bij de entiteit hoorde die erg in vorm kon verschillen, maar waarbij het niet zoveel uitmaakte hoe dat zat (er hoeft niet op gequeried te worden, gesorteerd etc.) Qua performance was toen het opslaan van JSON wel een goede optie.quote:Op maandag 13 april 2015 17:11 schreef Monolith het volgende:
[..]
Dat voor simpele configs dus en native JSON NoSql databases voor daadwerkelijke data.
Dat is leuk, maar ik zie niet in waarom dit specifiek in MySQL zou moeten. Ik weet wel dat PHP erg sterk verbonden is met MySQL, maar er is de laatste jaren heel erg veel aan het veranderen op database gebied.quote:Op maandag 13 april 2015 21:26 schreef Tijn het volgende:
Ik heb meerdere back-ends voor games gemaakt, waarbij er ook vaak JSON in een MySQL-database werd opgeslagen. Het is gewoon handig, want je hebt dan wel de juiste data bij elkaar met de juiste relaties, maar je hoeft niet je database te updaten wanneer de game wordt geupdate.
Voornamelijk omdat ik weet hoe dat werktquote:Op maandag 13 april 2015 21:31 schreef Monolith het volgende:
[..]
Dat is leuk, maar ik zie niet in waarom dit specifiek in MySQL zou moeten.
Precies, maar er zijn tegenwoordig bijvoorbeeld allerhande document databases die hun data opslaan in JSON formaat zonder vastgelegd schema waar je bovendien rechtstreeks op kunt queryen.quote:Op maandag 13 april 2015 21:35 schreef Tijn het volgende:
[..]
Voornamelijk omdat ik weet hoe dat werkt
Ja, dat weet ik. Maar wat zou het voordeel zijn om op zoiets over te stappen? Juist het queryen op die data is helemaal niet nodig, het wordt gewoon integraal naar de game gevoerd.quote:Op maandag 13 april 2015 21:37 schreef Monolith het volgende:
[..]
Precies, maar er zijn tegenwoordig bijvoorbeeld allerhande document databases die hun data opslaan in JSON formaat zonder vastgelegd schema waar je bovendien rechtstreeks op kunt queryen.
Er zijn doorgaans behoorlijke voordelen qua performance.quote:Op maandag 13 april 2015 21:39 schreef Tijn het volgende:
[..]
Ja, dat weet ik. Maar wat zou het voordeel zijn om op zoiets over te stappen? Juist het queryen op die data is helemaal niet nodig, het wordt gewoon integraal naar de game gevoerd.
Voor de gemiddelde applicatie is MySQL dan ook prima.quote:Op maandag 13 april 2015 21:47 schreef Tijn het volgende:
Ik kan me vooral voorstellen dat het handiger is om zoiets als MongoDB te gebruiken wanneer je cloud hosting gebruikt en er verschillende servers met elkaar data moeten syncen. Dat kan lastig zijn met MySQL (duplicate primary keys enzo). Maar wanneer het gewoon op 1 machine staat, heb ik weinig te klagen over de performance van MySQL, hoor.
Klopt, maar sommige gegevens wil je soms wel weer relationeel opslaan. Dan is zo'n JSON-veld wel een aardige concessie, als je een beetje van beide wilt.quote:Op maandag 13 april 2015 21:37 schreef Monolith het volgende:
[..]
Precies, maar er zijn tegenwoordig bijvoorbeeld allerhande document databases die hun data opslaan in JSON formaat zonder vastgelegd schema waar je bovendien rechtstreeks op kunt queryen.
Een andere optie is om ArangoDB te pakken, en de relaties ook gewoon als documenten op te slaan. Zoals zo vaak zijn er meerdere mogelijke oplossingen en is er niet echt een 'beste' oplossing.quote:Op maandag 13 april 2015 22:48 schreef robin007bond het volgende:
[..]
Klopt, maar sommige gegevens wil je soms wel weer relationeel opslaan. Dan is zo'n JSON-veld wel een aardige concessie, als je een beetje van beide wilt.
quote:What’s New in MySQL 5.7? (First Release Candidate)
Last week we proudly announced the first Release Candidate (RC) of MySQL 5.7. MySQL 5.7.7 includes additional enhancements and aggregates the Development Milestones Releases (DMRs) the MySQL team at Oracle previously delivered to the MySQL community.
With the first Release Candidate, it’s more important than ever that we hear your feedback on the pre-GA version in order to help ensure very high quality for the GA release.
MySQL 5.7 is an extremely exciting new version of the world’s most popular open source database that is 2x faster than MySQL 5.6, while also improving usability, manageability, and security. Some key enhancements include:
1. Performance & Scalability: Improved InnoDB scalability and temporary table performance, enabling faster online and bulk load operations, and more.
2. JSON Support: Native JSON support (JSON Labs Release).
3. Replication improvements for increased availability and performance. They include multi-source replication, multi-threaded slave enhancements, online GTIDs, and enhanced semi-sync replication.
4. Performance Schema delivering much better insights. We’ve added numerous new monitoring capabilities, reduced the footprint and overhead, and significantly improved ease of use with the new SYS Schema.
5. Security: We are fulfilling “secure by default” requirements and many new MySQL 5.7 features will help users keep their database secure.
6. Optimizer: We have rewritten large parts of the parser, optimizer, and cost model. This has improved maintainability, extendability, and performance.
7. GIS: Completely new in MySQL 5.7 and including InnoDB spatial indexes, use of Boost.Geometry, along with increased completeness and standard compliance.
[...]
Nah, dit topic is al niet zo actief.quote:Op vrijdag 1 mei 2015 22:06 schreef henrivo het volgende:
We missen eigenlijk een symfony-topic, las dat er wel een laravel-topic is
Hier op Fok, of ben je in de war met Tweakers?quote:Op vrijdag 1 mei 2015 22:06 schreef henrivo het volgende:
We missen eigenlijk een symfony-topic, las dat er wel een laravel-topic is
De vraag is hoe dynamisch het geheel moet zijn en bij wie je de genereerfunctionaliteit neerlegt: devs of users. Je huidige idee lijkt me met de gegeven informatie vooralsnog storingsgevoelig en complex in onderhoud. Content toevoegen zoals links aan een menu kan natuurlijk via een database geschieden.quote:Op donderdag 7 mei 2015 17:05 schreef robin007bond het volgende:
Wat denken jullie over deze benadering? Of zie ik een manier over het hoofd die het makkelijker zou moeten maken?
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |