Comments (38)
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.
from laserweb4.
@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.?
from laserweb4.
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.
from laserweb4.
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
from laserweb4.
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?
from laserweb4.
@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 (:
from laserweb4.
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!
from laserweb4.
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.
from laserweb4.
@lautr3k that sounds like a good plan. Will the serial server and webpack server be the same or separate?
from laserweb4.
@tbfleming I think the Serial/GRBL/Smoothie servers should be independents (perhaps npm modules). That way it could be used in other projects.
from laserweb4.
The webpack server must be used only for development anda light http server for production.
from laserweb4.
Sounds good.
from laserweb4.
@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
from laserweb4.
@Cinezaster Go for it ;)
from laserweb4.
So... are we moving from ES5+knockout to ES6+React? Should I stop writing what I'm doing, learn React and start over?
from laserweb4.
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.
from laserweb4.
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
.
from laserweb4.
Congrats on the Fabrica hire! Looking forward to seeing the end result.
from laserweb4.
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.
from laserweb4.
Ho! and please do not post directly on this repository, we will follow the same github guidline as Smoothieware project :
- Fork the original repositiory.
- Clone the forked repository.
- Create a new branch for your bugfix/feature.
- Commit your changes and push it back on Github.
- Submit your pull request (Only one feature per pull request).
In the same spirit an coding style guid will be available soon!
from laserweb4.
Is the cam module a feature, or all the tiny parts which make up the cam module?
from laserweb4.
If the module does not exist then it is a new feature. If the module exist try to fix one thing at time.
from laserweb4.
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.
from laserweb4.
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
.
from laserweb4.
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
.
from laserweb4.
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.
from laserweb4.
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.
from laserweb4.
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>...
from laserweb4.
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.
from laserweb4.
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.
from laserweb4.
I follow what @tbfleming said. Really appreciate the work you're putting into this @lautr3k.
from laserweb4.
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).
from laserweb4.
On the other hand, inline arg comments handle the case with multiple inner functions better.
from laserweb4.
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.
from laserweb4.
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.
from laserweb4.
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.
from laserweb4.
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.
from laserweb4.
@jorgerobles See above too
from laserweb4.
Related Issues (20)
- Missing Installation Instructions HOT 8
- Windows frontend cannot connect to Raspberry Pi server HOT 3
- program freezes on gcode generation HOT 34
- Allow gcode comments in (parenthesis) since some controllers error on semicolon comments
- Features request HOT 10
- Features request HOT 2
- Clipped (cropped) Inkscape SVG files do not maintain the clipping in LW4 HOT 2
- Problems on firefox with popup/setState HOT 16
- Feature Request: Hatches
- Jerky motion due to too many instructions HOT 3
- Changes to frontend not reflected HOT 7
- Y axi is opposite HOT 5
- Where do I get the frontend for Linux HOT 8
- No supported Firmware Detected on Linux AppImage HOT 3
- Cut internal first HOT 1
- laser test button HOT 9
- Laserweb 4 and Mac OS Sonoma HOT 1
- laser starting point HOT 2
- Can I choose a language? HOT 1
- how to tell laser to cut inside or outside the line in laser web HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from laserweb4.