Reprise du message précédent :
Bah non justement fin je le ferai peut-être sur notre erp de dev, mais avec un serveur pas chez online ca risque de piquer un peu
 
Et Ce qui me casse les couilles pour les dédiés chez online c'est que pas de raid hardware a part sur le entreprise.
 
Et les rpn aussi sont sur le haut de gamme
 
On connaît pas le lien entre un dédié et le sql en saas.  
 
Et aucune infogérance même sur des gros projets. Donc l'option "chef de projet" c'est un peu de la flute
 
Donc vu que je veux plus me faire chier à gérer les majs, les patchs et tout je suis à moitié parti sur du docker hébergé
 
/mavie d'admin de merde

+1

J'ai voulu essayer, l'interface est encore toute bugguée

 
 https://www.clever-cloud.com/ ?

Scalingo pour le moment c'est le même principe.

2017 bordel de merde, 2017 et t'as encore des développeurs qui font ça  
 

/**
 * Class article
 * @property $id
 * @property $category
 * @property $user_id
 * @property $name
 * @property $summary
 * @property $description
 * @property $picture
 * @property $created_at
 * @property $updated_at
 */
class Article extends UploadContentActiveRecord implements Searchable
{
    // ...
}

/**
 * Class article
 * @property $id
 * @property $category
 * @property $user_id
 * @property $name
 * @property $summary
 * @property $description
 * @property $picture
 * @property $created_at
 * @property $updated_at
 */
class Article extends UploadContentActiveRecord implements Searchable
{
    // ...
}

lapin compris ton problème exactement

/**
 * Class article
 * @property $id
 * @property $category
 * @property $user_id
 * @property $name
 * @property $summary
 * @property $description
 * @property $picture
 * @property $created_at
 * @property $updated_at
 */
class Article extends UploadContentActiveRecord implements Searchable
{
    // ...
}

C'est tres courant en PHP, et c'est pour les produits JetBrains surtout, car dans ce cas l'auto completion marchera nickel.

Les propriétés ne sont pas déclarée explicitement, en gros :
 

class Foo
{
    public function __construct()
    {
        $this->bar = 'yolo';
    }
}

 
C'est malheureusement valide en PHP. Du coup pour que l'IDE ne soit pas perdu le @property est ajouté en début de classe (j'ai toujours du mal à comprendre l'intérêt de ce genre de chose puisque tu finis par taper quasiment le même nombre de caractères)

 
Non.
Peut-être que les débutants font ça couramment mais ça fait des années que je n'ai pas vu ça, heureusement.

 
 
Dites, concernant es6 modules, vous utilisez quoi comme outils pour générer vos bundles ?
Perso j'utilise webpack mais je ne suis pas un grand fan.  
Je trouve la config quelques peu "lourde", la doc n'est pas tip top et les changements d'api entre les version 1 à 3 rendent difficile de trouver des bonnes réponses sur google.
 
Par rapport à mon besoin (bundle) je trouve ça un peu overkill.  
Alors certes ça fait plein de super truc comme l'extraction d'assets, de css, etc.., mais pour être franc ça m'intéresse très peu.
 
 
J'ai regardé du côté de rollup, ça à l'air un poil mieux, un peu moins intrusif.
Des retours d'expériences dessus ?
 
 
Ou sur d'autres bundlers ?

Ca pourrait éventuellement servir si les types étaient renseignés (j'imagine que PHPStorm comprend), afin d'éviter de foutre de la PHPDoc "dans" le code.
 
Mais là, euh.

Oui là on est d'accord, c'est crade de ne pas déclarer la property sur la classe, mais il vaut mieux la typer avec de la doc, cela permet d'avoir une meilleur complétion et pour générer de la doc c'est plus cool.

 
Dans ce cas tu feras ça sur la propriété et non pas sur la classe :
 

class Foo
{
    /** @var string $bar */
    private $bar;
 
    public function __construct(string $yolo)
    {
        $this->bar = 'yolo';
    }
}

 
Mais plus j'utilise Yii Framework plus je me dis que ça c'est un détail comparé au reste

class Foo
{
    /** @var string $bar */
    private $bar;
 
    public function __construct(string $yolo)
    {
        $this->bar = 'yolo';
    }
}

Oui c'est comme ça que j'avais fait sur un projet perso en PHP il y a 8 ans

Notre dev nous à fait notre futur nouveau site en RoR, putain ça pootre

Ca existe encore RoR ?

Ben quoi ?

Ah c'est fini le hype pour RoR ?

J'en ai fais un peu, je trouve ça pas trop Trop de génération / de bordel (mais certainement parce que je suis noob dans ce language )

J'utilise webpack et c'est vrai que la configuration peut être assez complexe. Mais sa complexité est proportionnelle au cumul des tâches que tu veux accomplir.
 
 
I.e pour ton usage, ceci devrai suffire, si tu n'utilises pas babel, tu peux virer le loader.

const path = require('path')
const webpack = require('webpack')
 
const PROJECT_ROOT = path.resolve(__dirname)
 
module.exports = {
  context: PROJECT_ROOT,
  entry: './your-entry-file.jsx',
  output: {
    filename: 'app.js',
    path: path.resolve(PROJECT_ROOT, 'dist'),
  },
  resolve: {
    extensions: ['.js', '.jsx'],
    modules: [
      path.resolve('./node_modules'),
    ]
  },
  module: {
    rules: [
      {
        test: /\.js[x]?$/,
        exclude: /node_modules/,
        loader: 'babel-loader',
        options: {
          presets: ['es2015', 'stage-0'],
        }
      },
    ]
  },
}

 
PS: Y'a pas de changement d'API user entre la version 2.0 et la version 3.0, seulement des changements internes qui peuvent avoir des répercussions sur les plugins qui n'ont pas suivi les indications d'obsolescence.

Quelqu'un peut m'expliquer pourquoi le titre du topic s'affiche correctement sous Safari (Mac), mais pas sur Chrome ni FF
(J'ai l'impression que les caractères UTF8 passent pas du tout sur ces browsers alors que la DB et le site sont OK)
La base et le champ en DB sont en utf8mb4, la connexion pdo en utf8mb4...

https://www.trancegoa.org/forum/rec [...] galactique

Thx

Ça fonctionne avec Firefox et Chrome sous Android: problème de police qui n'a pas de glyphes pour ces caractères exotiques.
Edit: https://en.wikipedia.org/wiki/Bamum_Supplement

La page que tu me cites a le même problème

 
Ben faire du PHP en 2017

Il faut bien faire des jobs alimentaires parfois

ce GIF    
 
Sinon, c'est peut-être déjà passé mais au cas où : https://stateofjs.typeform.com/to/S5iLk9  

C'est super long et les choix sont ultra restrictifs. I've HEARD of it, and am NOT interested.

Super long ? Ca prend 5mn ...

'tain ouais, je viens de le faire c'était relou.

 
Merci pour ta réponse au fait   et dsl pour le retard.
Je suis bien conscient que la complexité soit liée à la polyvalence de l'outil, je suis juste surpris qu'il n'existe pas d'alternatives "simples" pour les taches les plus courantes.
 
Perso je bosse avec le couple typescript/angular, donc rien d'insurmontable non plus.
Et ça ne m'empêche pas de dormir la nuit, loin de la. Juste une légère impression que depuis 2-3 ans l'éco système js s'est parfois assis sur le KISS principle    
 
 
De mémoire l'api "loader" a été déprécié au profit de "use" dans webpack 3. C'est juste un warning, donc pas bien méchant, et pour le coup c'est même plutôt justifié.
 

 
Après ça me semble difficile de faire plus court si ils veulent être un tant soit peu exhaustif...
J'avoue que j'ai assez vite expédié les questions sur le back end et la partie tests.

 
Angular essaie de piquer Ember-CLI, ça devrait répondre à un usage simple et complexe.

 
Toutafé. Et honnêtement ça marche pas trop mal.
Mais dans les faits ça pousse quand même a adopter certains choix d'architectures.
Bossant en .Net je préfère éviter de rajouter une couche nodejs pour la partie frontend server(donc exit ng serve, hmr et le server side rendering)
 
Node ne me sert que pour le build de la partie javascript/sass.
ça implique quand même pas mal de customisation pour intégrer proprement angular à l’environnement .net (d'ou la config webpack à la mano)
 
 
Certes on pourrait éventuellement migrer sur un frontend nodejs mais là on est sur un tout autre débat.    

Node est utilisé pour générer les assets. Aucune obligation de s'en servir comme serveur (a moins que je ne comprenne pas ton commentaire)
 
J'y connais pas grand chose en Angular ou .Net.

Si tu fais ça c'est que tu as un soucis avec ton projet.
 
Si tu fais une app angular/react/tamere.js,  
Ton arbo c'est :  
/ mon projet
|--client (tout le code client de ton app)
|--server (tout le code server en php, .net whatever)
 
Si tu as un projet en node, le package.json des 2 projets tu peux le mettre à la racine, mais moi en général, j'estime que la partie client et la partie back sont 2 choses séparées, donc chacune a son package.json à elle.
 
Ensuite, tu laisses ton webpack/gulp/whatever te fournir un serveur web avec les assets qui vont bien. Ton code lui fait les appels à ton /api mais ton /api si il est bien fait il fait directement proxy sur ton serveur de dev en .NET, Java, PHP whatever.
 
Et quand tu build, la partie client se démerde pour packager ton code et la coller dans le dossier "/server/build" et ensuite tu lances la build de la partie back. et Basta, pas besoin de configuration farfelue dans tous les sens.

À vous lire, j'aimerais bien me former à Angular et tout ce que vous balancez (webpack/gulp/vosmeres)  
 
J'en suis encore à l'étape Symfony+jQuery, #oldschool

 
Je répond uniquement pour la partie SSR côté Ember. Pour le mettre en place, il faut effectivement que ton appli Ember soit servie par du Node (via ember-fastboot), mais tu n'as aucune obligation côté API.
Dis autrement, tu peux avoir ton API en .Net et ton appli Ember servie de son côté par Node + Fastboot, tout comme si tu avais tes assets servis par un NginX par exemple.

Oublie Angular 1
Essaye angular 2
Sinon essaie aussi React, il a l'avantage d'avoir une grosse communauté, d'avoir des composants natifs pour le mobile, et d'avoir des outils sympas pour bosser.
Pour bootstraper un projet avec react, facebook propose "create-react-app" qui a la particularité de te générer un projet avec tous les outils qu'il faut pour bosser et surtout en ayant du zero-config.