Reprise du message précédent :
Lutain, le client qui arrive pas à acheter avec sa CB via Stripe

Conséquence : on va ajouter un morceau d'API dans la partie serveur pour que le client, en cas d'erreur dans un process critique (genre l'achat ) puisse lui envoyer l'info.

J'arrive pas à reproduire le soucis, chezmoicamarche.org, même en prod. Fuck dat shit!

Comme quoi l'API sexy de stripe sur laquelle tu te touchais ne fait pas tout

 
L'API est excellente et je pense pas que ça vienne de là. C'est plutôt le JS côté client de notre site qui à l'air d'avoir un soucis, on dirait qu'il n'arrive pas à charger le JS de Stripe.

ReDim Preserve ça marche que sur la dernière dimension

C'est pas juste équivalent à un truc du genre implémentation explicite d'interface ou qqch comme ça ?

 
Tiens à propo de Sripe, c'est mieux que Sage Pay ? Comparaison de tarif ? Chez sage pay, c'est un fixe à payer, alors que Stripe, c'est au pourcentage je crois.
 
On a en charge un Magento et bientôt on va en avoir plusieurs... Pour le moment on est sur du Sage Pay.
 

Je connais pas Sage Pay. Mais chez Stripe, c'est plutôt simple en terme de tarifs (2.9% + 30c par paiement validé)

Et en terme d'utilisation, c'est trivial.

 
En terme d'utilisation concernant magento, ya une extension très utilisée et rien à faire de spécial pour que ça marche. Le choix pour Sage Pay a été fait avant qu'on récupère le bouzin. Je vois qu'il y a aussi une extension pour stripe d'ailleurs. Faudrait que je me renseigne pour une comparaison des tarifs quand même au cas ou le client viendrait nous en parler un jour.

Bon ben le soucis pour le paiement ne venait pas de chez nous :
 

 
Ouch... C'est hors de prix !!!

Ah ouais putain en plus j'oubliais de préciser Preserve. Les arrays en VB6, ça fait longtemps

 
Je pense que ça doit dépendre du prix moyen des articles vendus... Je voulais dire comparé à Sage Pay. Sage Pay prend pas de pourcentage, donc pour de fortes sommes, ça doit être mieux.

Non mais c'est très bien, selon les volumes / prix unitaire ça peut le faire.
 
On a des tarifs fixes à la transaction (authorize + capture) de l'ordre de quelques centimes... Mais on a un gros volume aussi

 
Ouais enfin là c'est le tarot flat sans négo. Quand tu commence à avoir du volume, tu te doute bien que tu reste pas à ce tarif

 
Enfin ils ont pas la sécu et la retraite

 
?
 
Pour la sécu, bien sûr que si. Et les niveaux de remboursement valent bien ceux de la sécu francaise, ste bonne blague. Ensuite, une fois à l'hopital, tu ne payes rien et il n'y a aucun ticket modérateur ou autre.
Pareil pour le doc, tu ne payes rien. Tu payes certains médocs comme en France. Le système est très semblable.
 
Après, tu peux prendre une assurance privée pour avoir des rdv plus rapidement ou avoir accès à certains hôpitaux privés. Mais en France, sans complémentaire santé, t'es mal aussi.
 
Les hôpitaux sont ici bcp plus clean et mieux organisés, de même que les urgences. PAR CONTRE, j'ai entendu dire que cela pouvait dépendre des régions. Où je suis (Reading), ça marche bien et je n'ai jamais eu à attendre pour quoi que ce soit, mais il parait que c'est pas partout comme cela. L'Angleterre continue d'avoir la réputation d'un pays qui ne soigne pas ses habitants à cause de ce qu'avait fait Thatcher. La réalité est heureusement complètement différente.
A noter que quand tu viens en Angleterre, même sans boulot, tu as accès aux soins (comme si tu avais accès à la CMU en France) d'office. Aucune complication à ce niveau.
 
Au niveau des retraites par contre, là c'est différent. Tu es libre ou non de cotiser pour ta retraite dans la plupart des cas. Sauf que c'est en train de changer et que la retraite est devenue obligatoire dans les entreprises de plus de x salariés ()je ne me souviens pas le nombre) et toutes les entreprises seront concernées l'an prochain.
Mais jusqu'à maintenant, c'est vrai que la retraite dépendait de ta volonté d'en avoir une ou pas.

Le NHS c'était des bouchers quand je vivais en UK : "vous avez mal à la gorge ? buvez du thé au citron bien chaud et couchez vous", ravi de voir que ça s'est amélioré.

question agile (je me fous toujours sur la gueule avec les mêmes).
 
Comment vous gérer la notion de scope à minima en agile ? je vais prendre un cas débile : refaire son toit. on peut décider de mettre un vélux, ou pas, de mettre une parabole, ou pas, d'avoir une cheminée (intégration avec le projet cheminée fait dans le salon), ou pas, etc...
 
On peut choisir le type de tuiles, etc... par contre il est certain qu'à minima, il faut que le toit soit recouvert, parce que ça c'est indispensable.
 
Comment vous gérer cet aspect, sachant que ça oblige :
- à estimer upfront combien ça coute de recouvrir le toit
- d'identifier très en amont que c'est un UC prioritaire
 
si on raisonne en mode "je prend une équipe de x devs sur Y sprint", comment savoir si l'équipe est dimensionnée correctement ?

Si j'ai un stream d'évènements avec de l'overlap possible et que je veux les répartir sur un jeu de "tracks" pour qu'il n'y ait pas d'overlap au sein d'une track (genre évènements de calendrier ou timeline de requêtes dans les outils de débug des navigateurs), il y a un algo propre?

 
 
tout vient à point : http://ecrans.liberation.fr/ecrans [...] re_1273735

Si tu as N évènements déjà classés par ordre chronologique de début et K tracks, tu prends tes évènements dans l'ordre d'arrivée, tu gères un tableau de K éléments contenant la date où chacune des track se libèrera. Pour chaque évènement (O(N)), tu as juste à trouver la première track libre (O(K)) et à mettre à jour sa date de libération. L'algo se fait en O(N*K).

 
tous les events ont la même durée ?

Ouh que non, et l'espace entre les events est arbitraire.

Mais la méthode de hephaestos fonctionne farpaitement, j'ai une timelime correctement layoutée (mais moche ofc, on se refait pas )

Yelle sur KEXP  
https://www.youtube.com/watch?v=wrJQOQiLpVI

T'es obligé de nous en faire profiter, salaud de communiste de merde?

Je chiffre a minima, et je propose les options chiffrés au PO. La difficulté est que certaones ont des liens ( genre si je fais des panneaux solaire, pas de velux ou l"'inverse : si je prends l'option A, l'option B coute moins chere)
Au final ça reste quand même un numéro d'équilibriste, dans lequel je cale le socle, et j'utilise les options comme variables d'ajustement en fonction de l'avancée en cours de projet (si tu ne te garde pas de marge d'ajustement en cours, c'est pas super agile). . Sachant que je préfère un socle stable à un socle + plein d'options mais tout fait à l'arrache

ca me fait penser a http://bikeshed.com/ directement
 
sinon, tu evalues comme pour les story points. Apres tu vois un total vague et base sur l'experience et tu evalues de combien de devs tu vas avoir pour le nombre de sprint, ou alors le temps et tu demandes le nombre de dev en consequence. Il te faut au moins un point de depart

J'ai déflagué KEXP
Et je viens de me crever les oreilles avec un tisonnier

 
T'es triste parce que ce genre de merde à hipster était cachée mais de moins en moins?

Yelle ? pour les hipsters ?

vos deux réponses sous-entendent donc un minimum d'étude avant d'entrer dans le mode agile donc...les mecs me vendent qu'il faut définir un budget et partir, et que "on verra bien ce qu'on a à la fin". D'où la métaphore du toit : les mecs sont pas capables de me garantir que le toit sera couvert...

PS : et merci pour bikeshed, je découvre et c'est plein de sagesse

en même temps l'agile ça commence par préférer les rapport humains sur les rapport contractuels. Là aller voir ses potes dans son coin pour essayer de les coincer par un contrat ...
Finalement, je pense que certaines personnes devraient faire développer en chine, ça libèrerait du talent localement. Parce que si c'est pour être gérés comme des chinois trop chers, ça sert à rien.

parce que bon un mec qui veut faire un toit en agile, il serait en train de bricoler une bâche plutôt que de se réunir à parler de vélux.

En même temps tous les projets de dev que j'ai vu ont eu d'énormes différences entre l'idée initiale et le résultat  
 
L'agile a l'honneteté de prendre ca comme postulat de base

 
Bah non KEXP.
Et là t'es tout dégoûté parce qu'un truc mainstream de porcasse est venu s'introduire dans ton intimité faite de barbes taillées à la serpette en cuivre et de fixies.
Du coup t'en as recraché ton smoothie au kale sur ta chemise à carreaux et t'es deg parce que c'est un modèle néo-vintage unique fabriqué par des ouvriers métallurgistes reconvertis.

j'ai déjà eu cette discussion 1000x avec eux :

Pour que ces gars existent à un instant T chez NN (moi y compris), c'est parce que quelqu'un nous paye.
Quelqu'un nous paye parce que parmis tous les endroit où il peut mettre son pognon, il juge que c'est une bonne idée de mettre une certaine somme d'argent sur l'ecommerce, et pas plus sur la Prod, le marketing, le commercial, la R&D, etc...
Il peut juger que c'est une bonne idée parce qu'il a une idée de ce que ça peut rapporter vs ce que ça peut couter
Il a cette idée parce qu'il a une idée de ce qu'on peut livrer pour un cout donné
Cette réflection a lieu à l'année N-1, donc dans un contexte très pauvre en information détaillée sur le projet. Note : les devs participent à cette phase pour donner une fourchette de cout. Je ne met aucune limites sur la fourchette, ça peut etre 50-800, mais je veux absolument que le projet tienne dedans. Le spread est significatif de ce fait. Dans mes tableaux, je ne prends que la borne haute, donc je ne suis pas pute sur le dimensionnement.

Donc nier le fait de donner une idée de ce qu'on peut livrer pour un budget donner, c'est nier le process, et c'est nier les raisons mêmes qui ont permis aux gens (moi y compris) d'être là pour pouvoir s'engueuler. Parce que si tu t'engages pas à livrer un minimum de résultats tangibles, ben c'est pas ton team qui a le pognon (mais une autre qui a montrer qu'elle allait livrer plus de valeur), donc t'as pas le pognon pour payer les gens, donc t'as pas de gens, et donc y'a meme pas de discussion à avoir.

c'est con, ça marche pas, c'est tout ce que tu veux, mais c'est le mode de fonctionnement dans une grosse boite. Et les gens le savent au recrutement. Faut pas me casser les couilles, quand tu signes pour rentrer à l'IT dans un groupe de 340'000 personnes, tu te doutes bien que tu rentres pas chez Facebook, ou alors t'es un poil naïf.

Chaque projet commence avec une phase de study, pendant laquelle on sort des requirements bien plus précis que dans la phase budgétaire (on a une spec fonctionelle complète, faite par mes gars, qui vont dans le système et le défonce pour bien identifier tous les gaps techniques), donc continuer à dire : non mais lache les thunes Jubi, on verra ce qu'on te livre au bout, c'est un tout petit peu pas acceptable. Qu'on ait pas une idée totale du scope je l'accepte volontiers, mais être capable de dire si le budget actuel suffit ou pas pour livrer les UC core, ça me parait franchement pas déconnant quand meme.

Encore une fois, de l'IT corporate, c'est pas de l'édition logicielle... c'est pas possible de dire : je fous 5 dev, et c'est eux qui font les évo produits, on verra ce qui sort à la fin... (et meme chez les gros éditeurs ça marche pas vraiment comme ça, en tout cas ceux qui sortent des produits avec des roadmap de features, des versions, etc...) : quand la boite dit : je sors le produit (un café par ex) le X, ben le X tout le dev est fait, et y'a un scope de base qui doit etre livré...sinon tu foires le lancement.

mais tout le monde a oublié que j'ai fais du windev et du flash ou quoi ?
Et puis j'ai un vélo giant aussi...

 
Il me semble qu'être agile c'est ajuster au fur et à mesure le retard/l'avancement du projet. Du coup si tu peux l'ajuster que dans un sens c'est plus de l'agile.
Ca veut pas juste dire que dans le cadre de ce projet les méthodes agiles ne sont pas adaptées?

 
absolument...on a les 2 approches, selon les projets on fait du waterfall ou de l'agile.
Celui là a commencé en waterfall, mais les mecs gueulent... en fait le CIO a rejeté la première estimation en disant que c'était trop cher et qu'il fallait explorer une autre approche, et ça les soule de rechiffrer l'approche...alors que depuis le temps qu'ils gueulent, ils auraient déjà fini...

en meme temps si les gars veulent faire de l'agile, mais ne veulent chiffrer qu'un scenario , c'est peut être pas côté business qu'il y a un pb