DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Denkt de browser niet dat het een HTML tag is en showt ie em daarom niet? Of is er ook in de source niets te zien?quote:Op maandag 24 maart 2014 23:41 schreef KomtTijd... het volgende:
[..]
Dat maakt het des te gekker, want zelfs al zou de hele code niet draaien, zou er op zijn minst een < moeten staat
Kortom, probleem is niet de code maar het hele bestand wordt niet aangeroepen.
[..]
Hoe kun je in hemelsnaam niet zien wat daar mis mee is? Zit je zonder syntax highlighting te werken ofzo? heb je error_reporting en alles uit staan?
"You know what Hell really is? It's not lakes of burning oil or chains of ice. It's being removed from God's sight."
Het is een bedrijf dat papier doet. Linkjes naar de 'nieuwe site' staan in de voorbeeldcode. Dat zulke archaïsche bedrijven weinig van het grote boze internet snappen verbaast mij weinig.quote:
[..]
Hoe kun je in hemelsnaam niet zien wat daar mis mee is? Zit je zonder syntax highlighting te werken ofzo? heb je error_reporting en alles uit staan?
Of het is gewoon nephew art. "Ik kan wordpress installeren, dus ik ben programmeur."
Carpe Libertatem
Het kost m'n baas meer om het niet te testen, dan om het wel te testen... Dan is de keuze snel gemaakt.quote:Op maandag 24 maart 2014 23:03 schreef TwenteFC het volgende:
Ik zou willen dat de baas er hier ook zo overdacht, maar helaas is devven niet onze core business en het enige waar hij omgeeft is dat zijn wensenlijstjes zo vlot mogelijk weggewerkt zijn.
In theory there is no difference between theory and practice. In practice there is.
Das wel heel erg korte termijn denken...quote:Op dinsdag 25 maart 2014 08:36 schreef slacker_nl het volgende:
[..]
Het kost m'n baas meer om het niet te testen, dan om het wel te testen... Dan is de keuze snel gemaakt.
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Why?quote:
[..]
Das wel heel erg korte termijn denken...
In theory there is no difference between theory and practice. In practice there is.
Het kost toch altijd meer geld om verderop in het proces dingen te fixen dan voordat je software naar klant/publiek doorzet. Ik weet verder niet in welke tak jij precies werkzaam bent, maar das toch wel redelijk algemeen?quote:
Op
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Dat kan je dus voorkomen met TDD. Door je spullen daar al gelijk goed op te bouwen kost het je later veel minder tijd om rare bugs op te lossen. Omdat je alle losse componenten getest heb hoe je alleen maar het component wat voor het probleem zorgt te debuggen.quote:
[..]
Het kost toch altijd meer geld om verderop in het proces dingen te fixen dan voordat je software naar klant/publiek doorzet. Ik weet verder niet in welke tak jij precies werkzaam bent, maar das toch wel redelijk algemeen?
phluphy for president!
Het grootste gedeelte hangt nog in elkaar met een index bestand waar staat "include "$_GET['pagina']".include.php"quote:
[..]
Het kost m'n baas meer om het niet te testen, dan om het wel te testen... Dan is de keuze snel gemaakt.
En nog erger is paginas met meerdere niveaus die dan bijv.
400.include.php heet
daar staat dan in
| 1 2 3 4 5 6 7 | if(isset($_POST)){ include "400_opslaan.inc.php" }else if($_GET['actie'] == 'blaa'){ include "400_blaa.include.php }else{ include "400_formulier.include.php } |
Kan wel janken soms. Helemaal met variabelen die nergens gedefinieerd worden en dat je gewoon 5 minuten kwijt bent aan het zoeken van die variabele wat dan een hidden post veld is.
Goffedomme.
Dan zou empirisch bewijs dit ook weerspiegelen in termen van productiviteit; er is geen consistente lijn te trekken door empirisch bewijs wat dat betreft. Zeer zeker niet in een industrial setting, waar de trend lijkt dat het productiviteit negatief beinvloedt.quote:Op dinsdag 25 maart 2014 15:24 schreef WyriHaximus het volgende:
[..]
Dat kan je dus voorkomen met TDD. Door je spullen daar al gelijk goed op te bouwen kost het je later veel minder tijd om rare bugs op te lossen. Omdat je alle losse componenten getest heb hoe je alleen maar het component wat voor het probleem zorgt te debuggen.
Zelfs, tegen de verwachtingen in, heeft het geen consistent effect op de interne kwaliteit van code. Vooral coupling en cohesie lijden eronder (complexiteit [McCabe's] wordt dan weer wel vaak beter, maar ik vind de hele meting van complexiteit zo enorm nietszeggend, fungeert een beetje als surrogaat van LOC).
Lees goed wat er staat: Het kost meer geld om het *niet* te testen, dan om het wel te testen. Maw, zonder tests kost het mijn baas geld en met tests niet. Of minder.quote:
Het kost toch altijd meer geld om verderop in het proces dingen te fixen dan voordat je software naar klant/publiek doorzet. Ik weet verder niet in welke tak jij precies werkzaam bent, maar das toch wel redelijk algemeen?
Verder is het niet helemaal waar wat je zegt, maar deel ik die mening wel, al ben ik nu eea aan het lezen dat wat anders zegt, onder meer door meer testdriven development te doen.
In theory there is no difference between theory and practice. In practice there is.
Ben alles behalve een pro in TDD maar ik geloof ook wel dat het op de lange termijn zorgt voor code die veel beter te managen is.
En het is sowieso niet verkeerd om vooraf door middel van tests je functionaliteit af te bakenen.
Essentieel lijkt me wel dat je tests ook van een behoorlijk niveau zijn en dat je het ook consistent doorvoert, merk dat ik hier zelf ook wel eens "fouten" in maak. Dat ik onderdelen niet of slecht test.
En het is sowieso niet verkeerd om vooraf door middel van tests je functionaliteit af te bakenen.
Essentieel lijkt me wel dat je tests ook van een behoorlijk niveau zijn en dat je het ook consistent doorvoert, merk dat ik hier zelf ook wel eens "fouten" in maak. Dat ik onderdelen niet of slecht test.
En hoe geldt die curve niet voor iemand die niet z'n tests van tevoren schrijft, maar direct na het implementeren van z'n methode? Of tijdens het schrijven van z'n methode? En heb je empirisch bewijs die de bewering dat TDD kostenefficiënt is steunt?quote:
[..]
Lees goed wat er staat: Het kost meer geld om het *niet* te testen, dan om het wel te testen. Maw, zonder tests kost het mijn baas geld en met tests niet. Of minder.
Verder is het niet helemaal waar wat je zegt, maar deel ik die mening wel, al ben ik nu eea aan het lezen dat wat anders zegt, onder meer door meer testdriven development te doen.
[ afbeelding ]
[ afbeelding ]
En evenzo de vraag; waarom zou het niet even goed duurder zijn om na je tests de implementaties te schrijven? Je draait twee dingen om qua volgorde, maar wat heeft dat met kosten te maken?
Uit een systematische review:
quote:The available evidence from the trials suggests that TDD does not have a consistent effect on
productivity. The evidence from controlled experiments suggests an improvement in
productivity when TDD is used. However, the pilot studies provide mixed evidence, some in
favor of and others against TDD. In the industrial studies, the evidence suggests that TDD yields
worse productivity. Even when considering only the more rigorous studies (L2 and L3), the
evidence is equally split for and against a positive effect on productivity. Table 12-5 classifies
the trials according to effects on productivity.
[ Bericht 7% gewijzigd door Diabox op 26-03-2014 01:02:51 ]
Of je voor of na je implementatie tests schrijft boeit me niet. Zolang je ze maar schrijft. En het gaat hier over de kosten van verandering die niet een stijle curve omhoog hebben. Dus het dogma: 'veranderingen laat in het proces kosten veel geld' wordt hiermee van tafel geveegd. Het gaat hierbij niet om, vooraf of achteraf tests schrijven, beide varainten hebben voordelen. Ik doe zelf soms tests schrijven en dan coden of achteraf schrijven. Ligt eraan wat ik aan het doen ben.quote:
[..]
En hoe geldt die curve niet voor iemand die niet z'n tests van tevoren schrijft, maar direct na het implementeren van z'n methode? Of tijdens het schrijven van z'n methode? En heb je empirisch bewijs die de bewering dat TDD kostenefficiënt is steunt?
En evenzo de vraag; waarom zou het niet even goed duurder zijn om na je tests de implementaties te schrijven? Je draait twee dingen om qua volgorde, maar wat heeft dat met kosten te maken?
Uit een systematische review:
[..]
Ik ben er wel van overtuigd dat zonder tests te maken de kosten van changes omhoog schieten.
Wat is overigens de definitie van productiviteit in die onderzoeken?
[ Bericht 2% gewijzigd door slacker_nl op 26-03-2014 08:01:40 ]
In theory there is no difference between theory and practice. In practice there is.
Ah, ja dat je tests wilt schrijven kan ik het niet meer dan eens mee zijn (zeer zeker vanuit een developer perspectief). Dacht meer dat je TDD schaalde boven andere methodieken waarbij werd getest, maar nu begrijp ik je beter.quote:
[..]
Of je voor of na je implementatie tests schrijft boeit me niet. Zolang je ze maar schrijft. En het gaat hier over de kosten van verandering die niet een stijle curve omhoog hebben. Dus het dogma: 'veranderingen laat in het proces kosten veel geld' wordt hiermee van tafel geveegd. Het gaat hierbij niet om, vooraf of achteraf tests schrijven, beide varainten hebben voordelen. Ik doe zelf soms tests schrijven en dan coden of achteraf schrijven. Ligt eraan wat ik aan het doen ben.
Ik ben er wel van overtuigd dat zonder tests te maken de kosten van changes omhoog schieten.
Variabel, zitten er volgens mij meerdere tussen die ook LOC/u mee beschouwenquote:Wat is overigens de definitie van productiviteit in die onderzoeken?
Iemand ervaring met php-opencloud? https://github.com/rackspace/php-opencloud
Voor interactie met object stores, heb namelijk half succes en half niet maar er is zo weinig over te vinden, en namespaces etc is nog wat ingewikkeld voor mij
Verbinding maken lukt, containers opvragen lukt, containers aanmaken lukt.
Maar service lijst (catalog) opvragen gaat fout.
Account gegevens natuurlijk verwijderd.
Zoals je ziet kan hij de functon getRegion niet vinden, die zit ergens in autoloaded classes.
Maar dit is de eerste keer dat ik met een paket met autoloader werk en waar de vendor map dmv composer is geinstalleerd.
Vendor map is dan wel verplaats vanuit de root, maar lijkt mij geen probleem
[ Bericht 42% gewijzigd door Darkomen op 27-03-2014 16:14:22 ]
Voor interactie met object stores, heb namelijk half succes en half niet maar er is zo weinig over te vinden, en namespaces etc is nog wat ingewikkeld voor mij
Verbinding maken lukt, containers opvragen lukt, containers aanmaken lukt.
Maar service lijst (catalog) opvragen gaat fout.
Account gegevens natuurlijk 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 27 28 29 30 31 32 33 34 | <?php require_once "vendor/autoload.php"; use OpenCloud\OpenStack; $client = new OpenStack('', array( 'username' => "", 'password' => "", 'tenantName' => "" )); $client->authenticate(); echo '<pre>'; $catalog = $client->getCatalog(); // Return a list of OpenCloud\Common\Service\CatalogItem objects foreach ($catalog->getItems() as $catalogItem) { $name = $catalogItem->getName(); $type = $catalogItem->getType(); if ($name == 'cloudServersOpenStack' && $type == 'compute') { break; } // Array of OpenCloud\Common\Service\Endpoint objects $endpoints = $catalogItem->getEndpoints(); foreach ($endpoints as $endpoint) { print_r($endpoint); if ($endpoint->getRegion() == 'NL') { echo $endpoint->getPublicUrl(); } } } |
| 1 2 3 4 5 6 7 8 9 | stdClass Object ( [adminURL] => https://compute.stack.cloudvps.com/v2/OBJSTOREKEY [region] => NL [internalURL] => https://compute.stack.cloudvps.com/v2/OBJSTOREKEY [publicURL] => https://compute.stack.cloudvps.com/v2/OBJSTOREKEY ) Fatal error: Call to undefined method stdClass::getRegion() in /var/www/objStore/catalog.php on line 30 |
Zoals je ziet kan hij de functon getRegion niet vinden, die zit ergens in autoloaded classes.
Maar dit is de eerste keer dat ik met een paket met autoloader werk en waar de vendor map dmv composer is geinstalleerd.
Vendor map is dan wel verplaats vanuit de root, maar lijkt mij geen probleem
[ Bericht 42% gewijzigd door Darkomen op 27-03-2014 16:14:22 ]
Ik zit met de volgende structuur:
Een tabel met categorieën
Een linktabel, die product_id - categorie_id koppels bevat
Een productentabel
Hoe kan ik nu alle categorieën die bijvoorbeeld meer dan 2 producten met een bepaalde eigenschap bevatten, ophalen? Ik zit redelijk vast.
Een tabel met categorieën
Een linktabel, die product_id - categorie_id koppels bevat
Een productentabel
Hoe kan ik nu alle categorieën die bijvoorbeeld meer dan 2 producten met een bepaalde eigenschap bevatten, ophalen? Ik zit redelijk vast.
Smile like you mean it
www.wefut.com
www.wefut.com
Wat heb je geprobeerd?quote:
Ik zit met de volgende structuur:
Een tabel met categorieën
Een linktabel, die product_id - categorie_id koppels bevat
Een productentabel
Hoe kan ik nu alle categorieën die bijvoorbeeld meer dan 2 producten met een bepaalde eigenschap bevatten, ophalen? Ik zit redelijk vast.
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
- Subquery, maar dat vindt mijn server niet erg leuk.quote:
- Een dubbele JOIN met GROUP BY, werkt, maar ik vermoed dat dat niet de meest efficiënte oplossing is.
Smile like you mean it
www.wefut.com
www.wefut.com
Iemand die mij uit de brand kan helpen.Toen ik mijn Wordpress website had opgezet een aantal jaar geleden werd automatisch bij elke pagina "| website naam" toegevoegd achter elke pagina titel.Nu wil ik dit weer realiseren, met uitzondering van de homepage.De code die ik nu heb is als volgt:1
Waar voeg ik de statische titel toe....?
| 1 | <title><?php if (is_home () ) { bloginfo('name'); } elseif ( is_category() ) { single_cat_title(); echo ' - ' ; bloginfo('name'); } elseif (is_single() ) { single_post_title(); } elseif (is_page() ) { single_post_title(); } elseif ( is_404() ) { echo 'Pagina niet gevonden'; } else { wp_title('',true); } ?></title> |
Waar voeg ik de statische titel toe....?
Dus eigenlijk wil hij wil dat je gaat testen, maar moet je het hem niet direct vertellen. Als er vaak aanpassingen in bestaande code gedaan worden, maken unit tests het leven makkelijker en kun je sneller opleveren.quote:
[..]
Ik zou willen dat de baas er hier ook zo overdacht, maar helaas is devven niet onze core business en het enige waar hij omgeeft is dat zijn wensenlijstjes zo vlot mogelijk weggewerkt zijn.
We hebben zelfs meer dan een jaar lang moeten zeuren een acceptatieserver, wtf
Gelukkig mijn meeste persoonlijke projectjes wel netjes getest, voor een groot deel.
PHPSpec FTW.
Probleem is natuurlijk wel dat we met een bak ontestbare code zitten, dat moet worden gerefactored.quote:
[..]
Dus eigenlijk wil hij wil dat je gaat testen, maar moet je het hem niet direct vertellen. Als er vaak aanpassingen in bestaande code gedaan worden, maken unit tests het leven makkelijker en kun je sneller opleveren.
Iemand ervaring met Symfony2 i.c.m. CCDNForumForumBundle? Ik installeer telkens eerst FOSUserBundle, so far so good. Dan require ik "codeconsortium/ccdn-forum-bundle": "dev-master" in de composer.json en update, daarna zet ik
new Knp\Bundle\PaginatorBundle\KnpPaginatorBundle(),
new CCDNForum\ForumBundle\CCDNForumForumBundle(),
in de bundle-array en zet ik
CCDNForumForumBundle:
resource: "@CCDNForumForumBundle/Resources/config/routing.yml" in routing.yml zoals allemaal is aangegeven in de docs. Maar, nu komt het,
Van stap 4 snap ik geen sodemieter
# app/config/config.yml
# Doctrine Configuration
doctrine:
orm:
default_entity_manager: default
auto_generate_proxy_classes: "%kernel.debug%"
resolve_target_entities:
Symfony\Component\Security\Core\User\UserInterface: Acme\YourUserBundle\Entity\User
entity_managers:
default:
mappings:
CCDNForumForumBundle:
mapping: true
type: yml
dir: "Resources/config/doctrine"
alias: ~
prefix: CCDNForum\ForumBundle\Entity
is_bundle: true
Moet ik dan het hele doctrine-gedeelte vervangen in app/config/config.yml? Moet ik het ernaast plaatsen? Snap er geen sikkepit van
new Knp\Bundle\PaginatorBundle\KnpPaginatorBundle(),
new CCDNForum\ForumBundle\CCDNForumForumBundle(),
in de bundle-array en zet ik
CCDNForumForumBundle:
resource: "@CCDNForumForumBundle/Resources/config/routing.yml" in routing.yml zoals allemaal is aangegeven in de docs. Maar, nu komt het,
Van stap 4 snap ik geen sodemieter
# app/config/config.yml
# Doctrine Configuration
doctrine:
orm:
default_entity_manager: default
auto_generate_proxy_classes: "%kernel.debug%"
resolve_target_entities:
Symfony\Component\Security\Core\User\UserInterface: Acme\YourUserBundle\Entity\User
entity_managers:
default:
mappings:
CCDNForumForumBundle:
mapping: true
type: yml
dir: "Resources/config/doctrine"
alias: ~
prefix: CCDNForum\ForumBundle\Entity
is_bundle: true
Moet ik dan het hele doctrine-gedeelte vervangen in app/config/config.yml? Moet ik het ernaast plaatsen? Snap er geen sikkepit van
