Duplication: backend about laserweb4

Hihihi :) With a comment like that, the balance changes dramatically. It may sound pretentious but this is my only salary (and I think not to be the only one). By the way thank you to all who contributed to this project in one way or another.

@tbfleming I really appreciate your work (in general and on LW), but for now it's a little too early to go further. Let me suggest a clean base before adding functionalities.

What I mean by a "clean base" :

• Dev environement (node, babel, webpack, docs generation, etc...).
• Main Layout -> Dock/Panes/Workspace (React componements).
• Data Events Manager (Redux).
• Code and Docs conventions.

After we discuss if everyone understand and is comfortable with that.

• If not -> Refactoring.
• Everyone is ok -> go further with identification of main modules and tasks distribution.

This make sense ?

P.S.: This may be off topic, but I think the backend (serial server) should have its own repo.?

[tbfleming]

Please don't get frustrated; I learned these lessons the hard way. Something I still don't do enough of: complimenting team members for what they do well.

Here are things I like about what you did:

• Nice development server and webpack setup. It avoids problems with the demo hack I set up.
• Nice split between action, reducer, and component files
• Cleanly-named files, classes, and functions
• Cleanly-implemented code; it's easy to see how it's set up
• Pulling the servers out to separate repositories

Here are things I like about how you've handled things:

• Willing to consider others' suggestions
• Willing to learn new technologies
• Willing to try multiple code organizations to see how it works out (e.g. dev branch vs. dev-es6 branch). This is a key aspect of rapid development.
• Jumping in to policy decisions when no one else was. Management is the most thankless job of software development.

My available time is way too unpredictable to take leadership here. e.g. right when I thought I might have more free time a new major work project started; two weeks ago I had no clue that it was coming.

However, they belong to the component, not the render function.

I do not understand why you say that.

Sorry, I skimmed the jsdoc blocks too quickly and misremembered where you documented the props at. I can't blame jsdoc on this one; I could have misremembered that with non-jsdoc comments.

Someone needs to do what you're doing; I really hope I don't cause you to back away.

Just to play devils advocate: But there is merit to using known architecture like React - since me coming in learning it, have more resources at hand to figure it out. On the other end, Seb's code is a little easier to read/understand

[tritao]

I've been following the new code developments but waiting for core work to settle a bit. Also a little confused as to what's the new plan is. Is the plan for LW to adopt a React/Redux architecture?

@tritao yeah sorry, after the last #2 chat we settled on ES5 as the plan. Since then @lautr3k has made comments like the one from https://plus.google.com/101442607030198502072/posts/6x1oKuBS1hb

and @tbfleming started working on the react/redux branch to do the cool things he needs (:

Which is sort of why I opened this issue, to get you all talking to each other! (:
Thats the only way for us all to be successful at this endeavour without stepping on toes (:

But to answer short version, yes looks like ES6 and React are welcome now (:

Also, as I keep telling @lautr3k (: we have a team of people willing to help he must just open issues with tasks so we can help him!

[tbfleming]

The backend on my branch is temporary and missing a ton of stuff that a real system needs (e.g. a release build). Actually the whole code I wrote is. I almost always start by running expirements, throwing out what doesn't work well (hard to follow code is an example) and refactoring stuff that does.

[tbfleming]

@lautr3k that sounds like a good plan. Will the serial server and webpack server be the same or separate?

@tbfleming I think the Serial/GRBL/Smoothie servers should be independents (perhaps npm modules). That way it could be used in other projects.

The webpack server must be used only for development anda light http server for production.

[tbfleming]

Sounds good.

@Cinezaster wanted to do "I think the Serial/GRBL/Smoothie servers should be independents (perhaps npm modules). That way it could be used in other projects." for a long time

@Cinezaster Go for it ;)

[emteeoh]

So... are we moving from ES5+knockout to ES6+React? Should I stop writing what I'm doing, learn React and start over?

[tritao]

The last post from @openhardwarecoza seemed to imply it, at least I've been learning React/Redux the past few days with the impression that the project is moving to it.

I am also under that impression, but take what I say as I stand back and
wait to see if @lautr3k confirms.

To give you all a heads up, from 1 Oct, me and @lautr3k have to work
together on Fabrica for @arthurwolf, and some of this modularisation will
spill between the two projects - which is why I dont want to piss off
@lautr3k by calling shots (:

On Sep 27, 2016 5:14 PM, "João Matos" [email protected] wrote:

The last post from @openhardwarecoza https://github.com/openhardwarecoza
seemed to imply it, at least I've been learning React/Redux the past few
days with the impression that the project is moving to it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHVr28UUF8CrZDWNKankyDEd2ND0ksKEks5quTHOgaJpZM4KCawn
.

[funinthefalls]

Congrats on the Fabrica hire! Looking forward to seeing the end result.

Again sorry for the lack of communication.

Just released the new ES6 dev branch. Tell me what you think ?

I will begin implementing the communication module in the next day (as I work on Smoothie-Happy.js).

To avoid duplication of work it would be nice to know who want to do what?
Thanks to tell us if you plan or if you are already working on a module.

Ho! and please do not post directly on this repository, we will follow the same github guidline as Smoothieware project :

1. Fork the original repositiory.
2. Clone the forked repository.
3. Create a new branch for your bugfix/feature.
4. Commit your changes and push it back on Github.
5. Submit your pull request (Only one feature per pull request).

In the same spirit an coding style guid will be available soon!

[tbfleming]

Is the cam module a feature, or all the tiny parts which make up the cam module?

If the module does not exist then it is a new feature. If the module exist try to fix one thing at time.

[tbfleming]

The overhead could cause people to work in isolation for long periods to avoid submitting multiple requests. That makes it hard for people to progress on modules which interact with the delayed modules. e.g. I'd be tempted to delay creating a pull request for the cam module, even though it'd be useful for others to try out at a large number of intermediate development steps.

That type of policy is useful on projects with large mature code bases, but tends to hinder new development.

Here's the policy I enforce at work: don't break existing functionality on master. Use branches for intermediate breakage, but try to merge to master, with non-breaking changes, often. We have a fast-paced development environment at work that would collapse if we used pull requests.

I agree with Todd to a large degree. The moral at my job is the same,
self pace, pace fast, but stay responsible for what you ship, if you
break it, no biggie, just fix it.

In all cases clear communication solves any headache, open an issue when
you start working on something and post updates, if someone sees a
potential conflict from the discussion, its easy to see it, talk about
it, or help out.

Rapid development is the name of the game here. And experimental features
make it to master, gets dropped if no one uses it. At least thats how
lw1-3 was (:

On Sep 29, 2016 6:24 PM, "Todd Fleming" [email protected] wrote:

The overhead could cause people to work in isolation for long periods to
avoid submitting multiple requests. That makes it hard for people to
progress on modules which interact with the delayed modules. e.g. I'd be
tempted to delay creating a pull request for the cam module, even though
it'd be useful for others to try out at a large number of intermediate
development steps.

That type of policy is useful on projects with large mature code bases,
but tends to hinder new development.

Here's the policy I enforce at work: don't break existing functionality on
master. Use branches for intermediate breakage, but try to merge to master,
with non-breaking changes, often. We have a fast-paced development
environment at work that would collapse if we used pull requests.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHVr22-PKJHL3QxWXtSyQNJfux-a6Ocpks5qu-ZOgaJpZM4KCawn
.

I just have a quick question myself, es6 branch the one to use as
example? Or still dev?

On Sep 29, 2016 6:28 PM, "Peter van der Walt (Gmail)" <
[email protected]> wrote:

I agree with Todd to a large degree. The moral at my job is the same,
self pace, pace fast, but stay responsible for what you ship, if you
break it, no biggie, just fix it.

In all cases clear communication solves any headache, open an issue when
you start working on something and post updates, if someone sees a
potential conflict from the discussion, its easy to see it, talk about
it, or help out.

Rapid development is the name of the game here. And experimental features
make it to master, gets dropped if no one uses it. At least thats how
lw1-3 was (:

On Sep 29, 2016 6:24 PM, "Todd Fleming" [email protected] wrote:

The overhead could cause people to work in isolation for long periods to
avoid submitting multiple requests. That makes it hard for people to
progress on modules which interact with the delayed modules. e.g. I'd be
tempted to delay creating a pull request for the cam module, even though
it'd be useful for others to try out at a large number of intermediate
development steps.

That type of policy is useful on projects with large mature code bases,
but tends to hinder new development.

Here's the policy I enforce at work: don't break existing functionality
on master. Use branches for intermediate breakage, but try to merge to
master, with non-breaking changes, often. We have a fast-paced development
environment at work that would collapse if we used pull requests.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHVr22-PKJHL3QxWXtSyQNJfux-a6Ocpks5qu-ZOgaJpZM4KCawn
.

If everyone agrees we keep only 'master' and 'dev-es6', the others can be suppressed.
And if you want we can all work in the 'dev-es6' branch and tries to keep the 'master' branch clean. But in the long term I'm not sure it'll accelerate the development.

[tbfleming]

If everyone works in dev-es6, then it's like what I have at work, but just under a different name. We could do this:

• dev-es6: all development happens here. No dist/ or doc/ directories
• master: snapshots of dev-es6 go here. Includes dist/ and doc/.

If no one ever merges from master to dev-es6, and no one ever commits to master, except for merges from dev-es6 and dist/ and doc/ builds, then there's a small chance we won't hit the massive git problems that happen when git holds dist/ and doc/. I had to ban that practice at work and purge it from git history. Not fun.

It's not about accelerating development, it's about avoiding hindering development.

[tbfleming]

After many attempts working with automatic doc generation at previous jobs, I noticed the following:

• No one referenced the auto-generated docs, except management.
• Other developers and I skim source instead. We use smart editors to find our
  way around.
• Maintaining the special comment blocks is painful, especially since the syntax deviates from
  the code they're documenting. e.g. jsdoc's weird syntax for types.
• In source, where developers spend most time, they are hard to read.
• Because of all this, I eventually gave up on it and stopped promoting
  it to new employers.

Here's what jsdoc looks like:

 /**
  * Create and return an action creator.
  * @function
  * @param {String} type Action type (eg.: "ADD_SOMETHING").
  * @param {...String} [argsNames] Action creator arguments names.
  * @return {module:lib/redux-action~ActionCreator} Action creator.
  */
function actionCreatorFactory(type, ...argsNames) {

This seems easier to read:

// Return a new action creator
function actionCreatorFactory(
    type,           // Action type (eg.: "ADD_SOMETHING")
    ...argsNames    // Argument names
    ) {

If you want to document type, then TypeScript is your friend, especially since it enforces it at compile time:

// Return a new action creator
function actionCreatorFactory(
    type: string,           // Action type (eg.: "ADD_SOMETHING")
    ...argsNames: string[]  // Argument names
    ) {

Nitpick: Creator and Factory are synonyms; there's nothing wrong with actionCreatorCreator or actionFactoryFactory.

Here's an example where autogeneration falls flat:

/**
* Render the component.
* @return {String}
*/
render() {
    return <div>...

No. It doesn't. It returns something very different than a string. Typescript would complain loudly if you did this:

render(): string {
    return <div>...

[tbfleming]

For functions like render, which occur everywhere and have to follow React's rules, there's probably no point documenting what they do (they render) or what they return (a ReactElement). props should be documented since they vary between components. However, they belong to the component, not the render function.

For functions like render, which occur everywhere and have to follow React's rules, there's probably no point documenting what they do (they render) or what they return (a ReactElement).

You have probably right...

However, they belong to the component, not the render function.

I do not understand why you say that.

Definitely I am not the right person to lead this project! I hate to impose my way, and until now, I have tried to be as flexible as possible. But to be honest I'm frustrated. All the things I proposed or put in place are not good. And nobody really wants to take things in hand.

Please @tbfleming take things in your hand, I'm doing this for the fun and the fun is about to leave me, you obviously have a great professional experience, you know how to keep this kind of project and you also know how to manage a team.

[tritao]

I follow what @tbfleming said. Really appreciate the work you're putting into this @lautr3k.

[tbfleming]

This is a post to query preferences on coding and comment styles. Which style do you prefer? function can't work in all situations since it borks this.

Style 1: prefer =>. Arg doc at top.

// Set attributes on an object.
//
// objectType:  e.g. 'document', 'operation'. Case ignored.
// attrs:       e.g. {type: 'pocket', depth: 7}
// id:          ignored for objects which don't have an id
export const setAttrs1 = objectType => {
  let type = objectType.toUpperCase() + '_SET_ATTRS';
  return (attrs, id) => ({type, id, attrs});
};

Style 2: prefer function. Arg doc at top.

// Set attributes on an object.
//
// objectType:  e.g. 'document', 'operation'. Case ignored.
// attrs:       e.g. {type: 'pocket', depth: 7}
// id:          ignored for objects which don't have an id
export function setAttrs2(objectType) {
  let type = objectType.toUpperCase() + '_SET_ATTRS';
  return function(attrs, id) { return {type, id, attrs}; };
};

Style 3: outer function, inner =>. Arg doc at top.

// Set attributes on an object.
//
// objectType:  e.g. 'document', 'operation'. Case ignored.
// attrs:       e.g. {type: 'pocket', depth: 7}
// id:          ignored for objects which don't have an id
export function setAttrs3(objectType) {
  let type = objectType.toUpperCase() + '_SET_ATTRS';
  return (attrs, id) => ({type, id, attrs});
};

Style 4: prefer =>. Arg doc inline.

// Set attributes on an object.
export const setAttrs4 =
    (objectType  // e.g. 'document', 'operation'. Case ignored.
     ) => {
      let type = objectType.toUpperCase() + '_SET_ATTRS';
      return (attrs,  // e.g. {type: 'pocket', depth: 7}
              id      // ignored for objects which don't have an id
              ) => ({type, id, attrs});
    };

Style 5: prefer function. Arg doc inline.

// Set attributes on an object.
export function setAttrs5(
    objectType  // e.g. 'document', 'operation'. Case ignored.
    ) {
  let type = objectType.toUpperCase() + '_SET_ATTRS';
  return function(
      attrs,  // e.g. {type: 'pocket', depth: 7}
      id      // ignored for objects which don't have an id
      ) {
    return {type, id, attrs};
  };
};

Style 6: outer function, inner =>. Arg doc inline.

// Set attributes on an object.
//
// objectType:
// attrs:       e.g. {type: 'pocket', depth: 7}
// id:          ignored for objects which don't have an id
export function setAttrs6(
    objectType  // e.g. 'document', 'operation'. Case ignored.
    ) {
  let type = objectType.toUpperCase() + '_SET_ATTRS';
  return (attrs,  // e.g. {type: 'pocket', depth: 7}
          id      // ignored for objects which don't have an id
          ) => ({type, id, attrs});
};

The redux community prefers => over function. I used to prefer inline arg comments, like I showed yesterday, but changed my mind after trying these combinations.

Separate question: do you prefer setAttrs or setAttrsCreator? setAttrsFactory reminds me too much of Java's bureaucratic ways (battle scars).

[tbfleming]

On the other hand, inline arg comments handle the case with multiple inner functions better.

Ho thank you for this list of proposals.

Personally I prefer the Style 3: outer function, inner =>. Arg doc at top.
I really have trouble to read the function definition when the arguments are on multiple lines.

What I like at the moment is: Using a function at the highest level of modules and use Arrows when inside of another class/method/function.

setAttrs going well ;) I think you made reference to actionCreatorFactory ? This is just to avoid confusion with a typo. But actionCreator or actionFactory or createAction are also acceptable for me.

[tbfleming]

Does the smoothieboard allow the web app to post files to its SD card? That would be a sweet way to preserve gui state and maintain sessions across different connected browsers.

[arthurwolf]

Yep it does

On Sat, Oct 1, 2016 at 5:43 PM, Todd Fleming [email protected]
wrote:

Does the smoothieboard allow the web app to post files to its SD card?
That would be a sweet way to preserve gui state and maintain sessions
across different connected browsers.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGpFf35bH0SI3uHeMkXagT39BJEKgKnks5qvn-_gaJpZM4KCawn
.

Courage et bonne humeur.

@jorgerobles See above too