Improving coding productivity

[ggerber]

Hi,
How can I improve my productivity when coding in Meteor? A big portion of my time is simply waiting for the building and linking processes to finish.

[smeijer]

Don’t wait for a build to complete. Even better; don’t have meteor running at all while developing big parts of code. Sometimes it is convenient to have, when fixing some bugs. But this should be something for a QA person; not for a developer. (I know I oversimplify this statement, there are some “but’s”)

What you should do; is get started with TDD (Test Driven Development), and with this Wallaby.js is a huge productivity boost. For more info on how to get started; see the topic I’ve created here:

Meteor 1.3 testing - with "meteor/meteor:x" package imports

Testing code that’s depending on Meteor modules can be quite hard. Even the blog mentioned at unit-testing-with-meteor-1-3 is depending on the Meteor global. And depending on globals is something we prefer not to do. That’s why we are working with import statements, isn’t it? So this is why I’m sharing my solution here. No more use of globals, import it all, but keep it testable. In this example we depend on two modules, meteor/meteor and kadira:flowrouter. It is an example, so forgive me that…

And especially the testdouble part:

Meteor 1.3 testing - with "meteor/meteor:x" package imports

I found out testdouble can be used after-all by using a require statement instead of an import. I did not realize at first, because in my understanding babel would have compiled import statements to require statements behind the scenes. And although this is true, it appeared that babel also moves the import statements to the top of the file. Thereby; the import statements are being placed above the td.replace statements; and thereby nothing is being replaced after all. You can easily verify th…

---

[tomtom87]

I put another 8gb of ram in my machine, my app compiles in seconds. Maybe not the best solution but it’s getting me paid faster I defo agree with @smeijer if you can create tests and your spec is that clear then do it, but if you gotta hit the ground running SSD and Ram is what you gonna need…

[gadicc]

Wallaby (mentioned above) and Hot Module Replacement (HMR) were my two top productivity boosts this year. For the latter, see React Hotloading in native Meteor is ready (i.e. no webpack).

There’s a react-hot-loader you can use with it, and if you understand how to handle updates yourself, you can get the same benefits for other parts of your code too.

[hwillson]

@ggerber

How can I improve my productivity when coding in Meteor?

Make sure you’re always working on multiple Meteor apps at the same time, so when one is building you’re context switching over to another one and coding. Yes this will also definitely drive you insane, but using webpack to speed up build times will also currently drive you insane, so you can’t win them all.

[gadicc]

@hwillson, what is the most common stuff you’re working on outside of react components? I’ve been keeping quiet about it until the actual stable release, but I recently renamed meteor-react-hotloader to meteor-hmr and support generic HMR code and other build plugins. Maybe I can write a guide on how to hot load some of the more common things in Meteor.

[hwillson]

Awesome news @gadicc! meteor-hmr looks great, thanks for your work on this! I am working mostly with React components these days, but to be honest the biggest area of slowness in my case is testing. I’m a huge fan of TDD and Meteor’s test/fail/code/pass cycle slowness is really painful. I tend to rely on test feedback more often than I manually check browser output, so I can’t wait until this area gets better. I know others (ref1, ref2) are making progress with testing solutions outside of Meteor that help speed things up, but I have yet to find the Meteor testing holy grail (rapid feedback but still easy to configure and use).

[qubitdev]

I am also getting an 8gb machine and i am going to pt it under my bed.Just had that idea half hour ago

[vikr00001]

My desktop compiles my current app fairly quickly, but my laptop is pretty slow. Today I tried out using a ram drive on the laptop. It’s much faster! The downside is, if you have a power outage you lose the full contents of the ram drive.

[gadicc]

@hwillson, stop whatever you’re working on until you have Wallaby.js setup From what you’ve written, this will change your life. It’s realtime, visual test feedback, in your editor . On every keystroke, every test affected by your current code is rerun in parallel, and you get instant notification if the line you’re working on breaks any tests, or with a split screen view, you can instantly watch your tests turn from red to green, jump between relevant test & code, etc. Check out the video on their front page. It’s a paid product, but I can’t emphasize how worth it it is, and it pays itself back in productivity quickly.

If configuration is the blocker, you can try it out first just for unit testing, which has a simple setup (tbh this is all I’m using it for so far). But after that, the guys at xolvio have a wallaby client/server config here that loads the entire Meteor context into wallaby, including the database. They do admit this slows down wallaby a lot, so it might take a full 1s for you to see the results To be clear, I have no affiliation with Wallaby, but it really it just this good. I recently spent an entire morning with a single split-screen (code+tests) in front of me, and when I finished, I felt like I’d just finished meditating. It’s code zen!

As I said, this and hot loading have totally changed my workflow this year.

[adrianmcli]

I gotta look into this Wallaby thing, you’re making it sound like the invention of the automobile!

[gadicc]

Hotloading and wallaby made me realize how detrimental waiting is to my workflow. I always assumed it was just the wasted time alone (for tests to run, for meteor to rebuild), but once you eliminate the wait, you finally understand how big the side affects are. It’s like when someone interrupts you in your code flow; there was an awesome comic/chart for this once, I couldn’t find it, but similar to this (top right):

It’s the same reason I keep my phone on silent when I’m working. Remove the interruptions and other distractions and you finally realize how super focused and how much more productive you can be in the same period of time.