Wouterr schreef:Hier in mn terminal werkt dit.leeftijd = "12 jaar" naam = "iemand" print "Hoi %s! Jouw leeftijd is %s" % (naam, leeftijd)

Ja, mij mij ook
Maar raw_input() niet 
Wouterr schreef:Hier in mn terminal werkt dit.leeftijd = "12 jaar" naam = "iemand" print "Hoi %s! Jouw leeftijd is %s" % (naam, leeftijd)

Maar raw_input() niet 
SELECT
p.id AS post_id, p.user_id AS post_user_id, p.thread_id AS post_thread_id, p.message AS post_message, p.deleted AS post_deleted, p.datetime AS post_datetime, t.id AS thread_id, t.category_id AS thread_category_id, t.user_id AS thread_user_id, t.subject AS thread_subject, t.message AS thread_message, t.sticky AS thread_sticky, t.closed AS thread_closed, t.deleted AS thread_deleted, t.datetime AS thread_datetime
FROM forum_posts p, forum_threads t WHERE p.thread_id = t.id GROUP BY p.thread_id ORDER BY p.datetime DESC Sjoerd schreef:Dit krijg ik bij een example van internet:Welke error krijg je dan?
Shahiem schreef:Zover ik weet dat de bedoeling is, is om voor elk onderdeel een branche aan te maken (of een fork) en dan na het uitvoeren van de bijgeleverde tests een pr te openen.Wat ik mij af vraag; Is het handig om bij elke aanpassing bij een repo om een pull-request te sturen of pas na een aantal aanpassingen.
Bijvoorbeeld ik werk mee aan een webshop repo maar ik voeg nieuwe dingen toe zoals
- Currency kiezen
- Shoppingcart
Shahiem schreef:Wat ik mij af vraag; Is het handig om bij elke aanpassing bij een repo om een pull-request te sturen of pas na een aantal aanpassingen.
Bijvoorbeeld ik werk mee aan een webshop repo maar ik voeg nieuwe dingen toe zoals
- Currency kiezen
- Shoppingcart
Xjessex schreef:Volgens mij is het inderdaad de bedoeling om voor elke nieuwe functie te brancen. Je kan dan later die branch mergen in de master wanneer je branch helemaal af en getest is.Bijvoorbeeld ik werk mee aan een webshop repo maar ik voeg nieuwe dingen toe zoalsEerdere citaten tonen
Shahiem schreef:Wat ik mij af vraag; Is het handig om bij elke aanpassing bij een repo om een pull-request te sturen of pas na een aantal aanpassingen.
- Currency kiezen
- Shoppingcart
Zover ik weet dat de bedoeling is, is om voor elk onderdeel een branche aan te maken (of een fork) en dan na het uitvoeren van de bijgeleverde tests een pr te openen.
Zo kan iedereen telkens 1 module inbrengen, dat is handiger dan dat iedereen ineens 4 modules gaat mergen en van de hele code niets meer klopt.
Natuurlijk hangt dit af van wat voor team je in werkt, uiteindelijk wijk je uit naar hetgeen dat je team fijn vindt werken.
toevoeging op 8 december 2014, 04:26:19:
En bij veel repos is een contributing file bijgevoegd waarin uitleg / regels staan over hoe het voor die repo moet gebeuren.
Xjessex schreef:Al kan je een view wel vaker gebruiken.Elke pagina heeft een eigen view.
Rik schreef:Bijvoorbeeld ik werk mee aan een webshop repo maar ik voeg nieuwe dingen toe zoalsEerdere citaten tonen
Shahiem schreef:Wat ik mij af vraag; Is het handig om bij elke aanpassing bij een repo om een pull-request te sturen of pas na een aantal aanpassingen.
- Currency kiezen
- ShoppingcartVolgens mij is het inderdaad de bedoeling om voor elke nieuwe functie te brancen. Je kan dan later die branch mergen in de master wanneer je branch helemaal af en getest is.Eerdere citaten tonen
Xjessex schreef:Bijvoorbeeld ik werk mee aan een webshop repo maar ik voeg nieuwe dingen toe zoalsEerdere citaten tonen
Shahiem schreef:Wat ik mij af vraag; Is het handig om bij elke aanpassing bij een repo om een pull-request te sturen of pas na een aantal aanpassingen.
- Currency kiezen
- Shoppingcart
Zover ik weet dat de bedoeling is, is om voor elk onderdeel een branche aan te maken (of een fork) en dan na het uitvoeren van de bijgeleverde tests een pr te openen.
Zo kan iedereen telkens 1 module inbrengen, dat is handiger dan dat iedereen ineens 4 modules gaat mergen en van de hele code niets meer klopt.
Natuurlijk hangt dit af van wat voor team je in werkt, uiteindelijk wijk je uit naar hetgeen dat je team fijn vindt werken.
toevoeging op 8 december 2014, 04:26:19:
En bij veel repos is een contributing file bijgevoegd waarin uitleg / regels staan over hoe het voor die repo moet gebeuren.
De master is altijd een (relatief) stabiele versie!
02: