Debugging Webpack app’s with WebStorm 2016.1

Posted on by
Reply

[Update Sep 2016: I just posted a support request with Webstorm asking for an updated tutorial on this subject. It’s Ticket WEB-23528]

It recently became possible to debug both server-side and client webpack applications with JetBrains’ WebStorm. The instructions came from a ticket WEB-20781, but they’re not in one place, so I figured I would write them out.

My application was built using react-starter-kit 0.5.1 – which is the current build as of mid-March 2016. These steps worked for me with WebStorm 2016.1 on OSX 10.10.5.

Update: WebStorm 2016.1 can automatically create the React Starter Kit 0.5.1 when you choose New Project…

Debugging Server-side Code

  1. Clone the react-starter-kit repo, then npm install as usual.

  2. You’ll need to tell webpack to generate source maps when debugging. Look in webpack.config.js for a line containing devtool (near line 204), and change it to:
    devtool: DEBUG ? 'source-map' : false,

  3. You also have to remove references to “hash” from the output filenames. Look in the same file near line 156 for a line like this, and change it to:
    filename: DEBUG ? '[name].js' : '[name].[hash].js',

  4. Create a new Run/Debug Configuration. Choose Run -> Edit Configuration, then add a “Node.js” item. Give the configuration a name, and if it isn’t already there, enter the path to your Node.js binary.

  5. Enter the path to your react-starter-kit project folder in “Working Directory”.

  6. For the “Javascript file:” enter the server-side code in the “build” directory. For react-starter-kit, it’s “build/server.js”

  7. Save the configuration by clicking OK.

  8. Build all the files by double-clicking “build” in the npm panel, or typing npm build in the command line.

  9. Set some breakpoints in the server-side code.

  10. In WebStorm, choose Debug (Ctl-D) for the configuration you created in 4. above. WebStorm starts debugging your server-side code, and should stop at breakpoints as expected.

Debugging Client-side Code

I haven’t needed to try these steps yet, but I understand this is the procedure:

  1. Follow Steps 1-3 above.

  2. Create a new Run/Debug Configuration. Choose Run -> Edit Configuration, then add a “JavaScript Debug” item. Give the configuration a name.

  3. Enter the URL to your app in the “URL:” field. For react-starter-kit, it’s http://localhost:3000

  4. Save the configuration by clicking OK.

  5. Start the application by clicking start in the npm panel, or typing npm start from the command line.

  6. Set some breakpoints in the client-side code. WebStorm should be debugging your client-side code, and should stop at breakpoints as expected.

Do you have comments/suggestions/improvements to these procedures? Leave a comment…

Hacking with React – A great book

Posted on by
Reply

I wanted to learn React, and I have been wandering around the Internet, looking at a zillion “how to get started” tutorials. I’m not sure what made me stop and look hard at Hacking with React, but I’m so glad I did.

Hacking with React provides a great combination:

  • a progression of straightforward, short lessons toward a working example program,
  • an interesting application (not another To-Do app, thank FSM!),
  • a Howto for setting up some of the confusing Node.js tooling (webpack, ESLint),
  • introduction to testing with Jest,
  • advice about best Node/Javascript/coding practices,
  • a decent understanding of how all these tools work together, and of course,
  • a great walkthrough of the concepts behind React.

At the end of the forty-some tasks (which take a while to complete if you actually do the work of understanding each lesson) you have a working React application, and a pretty good understanding of the basics of starting and building a React/Node application

The book is free to read, but you should buy this book to reward this excellent work. For $10, you’ll learn a lot.

WiTi Router Board update

Posted on by
Reply

I have the Witi Router working now with SQM-QoS – the bufferbloat-fighting technology that has been implemented in OpenWrt. Read more about Bufferbloat at Bufferbloat and the Ski Shop.

Demetris has made a build of OpenWrt Chaos Calmer (15.05) that has SQM-QoS built-in, so it’s a simple download and flash of the firmware. You can get a copy of the firmware at the mqmaker forum.

I haven’t tried it myself, but it looks as if stas2z’s BB version of the firmware also has the SQM-QoS as well at Alternate openwrt at mqmaker.

mqmaker.com WiTi Router – a new toy

Posted on by
Reply

I recently got my WiTi board from mqmaker.com – a high performance open-source router platform. It was funded from a IndieGoGo project and was based on OpenWrt, and thus is easy to customize.

The project doesn’t have a lot of documentation yet, so I just updated its description in the OpenWrt wiki to describe the initial out-of-box setup (pretty smooth – no surprises). Read it at: https://wiki.openwrt.org/toh/mqmaker/witi

Cmder for Windows – Alternative to PuTTY

Posted on by
1

For some unfathomable (to me) reason, Windows doesn’t seem to ship with a SSH program out of the box. I’ve used the venerable Putty in the past, but it makes you do a lot of work for a simple SSH session.

I recently ran across an open-source replacement called Cmder for Windows. Based on ConEmu, it bills itself as a “portable console emulator for Windows”. I find it a great replacement for PuTTY, Console, and Powershell. Cmder has a huge number of benefits:

  1. Cmder allows you to create a ssh session simply by typing ssh user@host — I’m immediately in love
  2. Cmder is easy on the eyes, with attractive fonts, default Monokai color scheme, and resizable windows
  3. If you get the “full” version, you get bash emulation with a Unix-y environment, including ls, grep, and even git
  4. Cmder will run off a USB stick
  5. … and it’s free (MIT License)

screen shot of Cmder window

Check it out at http://cmder.net

Comment to the FCC re: Consumer Router Firmware

Posted on by
Reply

Update: The deadline for filing has been extended to 9 October 2015, so you now don’t have any excuse for not sending in your opinion.

I filed the following comment on the FCC page regarding the new Proposed Rule that would (ultimately) prohibit individuals from installing third-party firmware (such as OpenWrt, DD-WRT, Tomato, and the myriad others) on their home router.

If you have an opinion on this, you should go to the FCC Comment Page and click the green SUBMIT A FORMAL COMMENT button.

You’re free to plagiarize my note, or take a cue from the Save WiFi page at LibrePlanet.org. I wrote:

I recommend that the FCC RESCIND its Proposed Rule, Document number 2015-18402 regarding wireless devices. The Proposed Rule is overbroad, would harm many communities of Americans, and is not warranted by the facts on the ground.

Although the FCC has the power to regulate equipment that generates radio frequencies, this is a heavy-handed rule that could be addressed other ways. Specifically, I am concerned about the ability of third parties to modify and create new firmware for “consumer routers.”

The proposed rule would require that router manufacturers lock down the RF portion of the router to obtain FCC approval. This “lock down” would prevent modification to the radio’s power, frequencies, etc to prevent it from radiating outside the specified limits. This is a laudable goal, but the application of this rule as written would result in undesirable consequences.

In practice, most radio functions are very tightly wedded to all the other factors of the hardware/software. The most likely way manufacturers would likely lock down the RF operation would be to make it impossible to modify any of the code in the routers.

There would be a number of adverse consequences both for me personally, to consumers in the US, and the networking industry. These consequences can be ameliorated by allowing the owners of routers to install their own code.

1) Security of the router. It is well known that vendor-supplied firmware for consumer routers often contain flaws. Just last week, the CERT released knowledge of a vulnerability to Belkin routers. See http://www.kb.cert.org/vuls/id/201168 The ability to install well-tested, secure firmware into a router benefits all consumers. The ability for a person to update their own router on a regular basis (as opposed to many manufacturer’s seemingly lackadaisical schedule) preserves security.

2) Research into the field of computer networking. Non-traditional research efforts (outside academia) lead to real improvements in the state of computer networking. An example is the CeroWrt project that developed the fq_codel algorithm. http://www.bufferbloat.net/projects/cerowrt The result of this multi-year effort was a major advance in performance for all routers. The fq_codel code has been accepted into the Linux kernel and now runs in hundreds of millions of devices. As a member of the team that worked on this, I assert that without the ease of modification of a consumer router to prove out the ideas, this improvement would likely not have occurred.

3) Personal learning environments. Individuals, as well as network professionals, often use these consumer routers as test beds for increased understanding of network operation. Losing the ability to reprogram the router would make it more expensive, if not prohibitive, for Americans to improve their knowledge and become more competitive.

4) I would incorporate all the other “talking points” listed on the Save WiFI page at: https://libreplanet.org/wiki/Save_WiFi

5) Finally, I want to address the FCC’s original concern – that these consumer routers are SDRs, and they must not be operated outside their original design parameters. While the goal of reducing radio frequency interference is important, the FCC has failed to demonstrate that the widespread practice of installing/updating firmware in consumer routers has caused actual problems. Furthermore, the FCC can use its current enforcement powers to monitor and shut down equipment that is interfering.

Creating a broad, wide-ranging rule to address a theoretical problem harms industry and individuals, and is an overreach of the rules necessary to preserve America’s airwaves.

Bufferbloat and the Ski Shop

Posted on by
Reply

Bufferbloat is undesirable latency caused by a router buffering too much data. It makes your kids say, “The Internet is slow today, Daddy”. It’s caused by routers and other network equipment buffering (accepting for delivery) more data than can be delivered in a timely way. Bufferbloat causes much of the poor performance and human pain experienced using today’s Internet.

Update: I found a way better analogy for explaining Bufferbloat. I write about it in my post Best Bufferbloat Analogy – Ever

First a story…

Imagine a ski shop with one employee. That employee handles everything: small purchases, renting skis, installing new bindings, making repairs, etc. He also handles customers in first-come, first-served order, and accepts all the jobs, even if there’s already a big backlog. Imagine, too, that he never stops working with a customer until their purchase is complete. He never goes out of order, never pauses a job in the middle, not even to sell a Chapstick.

That’s dumb, you say. No store would do that. Their customers – if they had any left – would get really terrible service, and would never know when they’re going to be served. And you would be right.

The Ski-Shop Router

Unfortunately, a lot of network routers (both home and commercial) work just like that fictitious ski shop. And they give terrible service. These routers have a single first-in, first-out queue for packets. All traffic is queued, regardless of whether it’s a big or small packet, whether there has been a lot of traffic from a particular source, or whether things are getting backed up.

Since the router has no global knowledge of what’s happening, it cannot inform a big sender to slow down, or throttle a particular stream of traffic by discarding some data (in the ski shop analogy, sending away a customer who has another long repair job). The dumb router simply accepts the data, buffers it up, and expects to send it sooner or later. To make matters worse, in networking (but not in ski shops), if delays get long enough, computers can resend the data, thinking that the original packet must have been lost. These retransmissions further increase bloat and delay, because there are now two copies of the same data buffered up, waiting to be sent…

This is the genesis of the name “bufferbloat” – the router’s memory gets bloated with buffers of packets. When the router doggedly determines to send that data, it blocks newer sessions from even starting, and the entire network gets slow.

What’s the solution?

The members of the CeroWrt team have been working for the last three years to solve the problem of bufferbloat. We’ve largely succeeded: the CeroWrt firmware works really well. CeroWrt users no longer see problems with “the internet being slow” even when uploading and downloading files, watching videos, etc. We have pushed those changes into the Linux Kernel, and also into OpenWrt mainline, and now its Barrier Breaker release contains the Smart Queue Management (SQM) fixes.

SQM introduces a new queueing discipline called fq_codel (see http://tools.ietf.org/html/draft-nichols-tsvwg-codel-02 and http://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00 for details) that can detect which flows (streams of data between two endpoints) are using more than their share of the bottleneck link (usually, the connection to the ISP).

SQM divides the traffic into multiple queues, one per flow, and sends packets from each queue in round-robin order. (The algorithm is somewhat more involved, so read the full description for details.) fq_codel also measures the time that each packet has been queued (its sojourn time). If packets for a flow have been in the queue for “too long”, then fq_codel either marks them for ECN (Explicit Congestion Notification), or discards a certain percentage of them, preventing the flow from using more than its fair share of bandwidth on the bottleneck.

Wait a minute – discarding packets? Doesn’t that make things worse?

It does slow the rate for the affected flow, but that is exactly what should happen. If a sender has sent so many packets that they’re building up in the router’s memory, then the router must offer back pressure for that flow by dropping/marking some of its packets.

In the meantime, all the other flows (in their own queues) have their packets sent promptly, since they’re not building up and their sojourn time stays low. This automatically keeps everything responsive: short packets, and those from low-volume flows automatically get sent first. The big senders, whose packets are dropped/marked, will re-send the data, but at a slower rate, bringing the entire system back into balance.

What about Quality of Service (QoS)? Doesn’t that help?

Yes, it helps a bit. If you configure your router for QoS, the router will use that information to prioritize certain packets. Good QoS settings can help certain traffic types by sending it first, ahead of the bulk traffic that’s buffered up. But there are several problems with QoS:

  • It doesn’t solve the problem of overbuffering. The QoS rules allow certain packets to go to the head of the queue. But the buffers from large flows are still there, and will have to be sent at some point. And those buffers will stand in the way of any newly arrived traffic that hasn’t been prioritized.
  • As a corollary, there’s no throttling of the big senders: they don’t get early feedback that they are using more than their fair share of the capacity. If the queue/delay gets large enough, the sender could even retransmit the data, making the overall situation worse.
  • It’s annoying to configure QoS. You have to understand how to configure the router and manually make the changes. This is something that only a network geek could come to enjoy. It’s also a maintenance hassle: if you hear about a new application, it may not work well until you adjust the QoS rules to take it into account.
  • Finally, QoS doesn’t help for the download direction. It can improve traffic being sent from your local (home) network toward the Internet. But if the equipment at the far end at your DSL or cable provider is bloated (and very often it is), then QoS in your router won’t make things any better.

The fq_codel and other algorithms in CeroWrt handle all this automatically. The only configuration parameters are what kind of link you have (DSL, Cable, etc.) and the speeds of those links. You don’t have to adjust QoS settings or make other adjustments.

Is my network affected by Bufferbloat?

Quite possibly – here’s one symptom: If the network works well when no one else is using it (early morning, or late at night after everyone else is asleep), but gets slow when others are on the net, then you are suffering from Bufferbloat. Another symptom is if your voice, video chat, or gaming degrade when others are using the network.

Here’s a more scientific test. The DSLReports Speed Test http://dslreports.com/speedtest runs a latency measurement during the download and upload speed tests. (Most speed test sites only measure a few pings when the line is idle.) If the latency gets high on this test, then your router is probably bloated. You can also check out the Quick Test for Bufferbloat on the CeroWrt site for additional information.

What can I do about this?

Three years of network research have paid off: the networks work great at our houses. Our algorithms have been adopted and implemented in the Linux kernel, other operating systems, and an increasing set of commercial network equipment. Our changes have been pushed in to the OpenWRT project. We are making the code available at no charge, and are encouraging all vendors to embrace it.

Regrettably, nearly every piece of equipment with a network connection – home router, ISP headend and DSLAM, phone, personal computer, laptop, tablet, even big commercial routers and switches – needs to have some form of SQM installed. We now have the technology, and it’s simple, but it needs to be deployed.

TL;DR – What you can do about Bufferbloat at your home

  • Consider installing the stable OpenWrt Barrier Breaker firmware on your router. The luci-app-sqm and sqm-scripts packages include the enhancements that we’ve tested and then pushed into the OpenWrt mainline source code. Use the Supported Devices page to find your router, then read the SQM/fq_codel HOWTO. If you don’t want to do all that…
  • Call your router vendor’s support line. With the information from the DSLReports Speed Test in hand, you can mention that the ping times get really high when up/downloading files, and that it really hurts your network performance. Ask if they’re working on the problem, and when they’re going to release a firmware update that solves it. Leave a comment here with their response – I’d love to hear.

An earlier draft of this note appeared in the Bloat and Codel mailing lists. See https://lists.bufferbloat.net/pipermail/codel/2014-February/000802.html Latest update 3May2015

More magma…

Posted on by
Reply

We have been planning a trip to Iceland (mostly to see the aurora) next year. I am now looking into tours that go near the volcano at Bárðarbunga and Holuhraun as well.

I think that land tours (I would love to stand next to the lava front) are out of the question, since the authorities have closed the area for ~18 miles around.

But there appear to be a couple air tours flying from Akureyri to Bárðarbunga, Holuhraun, and over the Askja crater for a little more than US$300 per person. The view from the planes can been seen in these Youtube Videos… I’m psyched.

A Memorization Tip

Posted on by
Reply

I have given out this tip in past years to people in Revels North who’re preparing for the Christmas Revels show…

I found this trick for memorization in a wonderful book, Don’t Shoot the Dog, The new art of teaching and training, by Karen Pryor. It talks about modifying behavior — yours and others. (One way of modifying behavior is shooting the dog. But she talks about lots of other—usually more appropriate—ways to change behavior.) She tells about coaching, teaching, and maybe even making things better in your life. And it’s a fun read…

But back to memorization: The trick is to learn the last verse first, then the next-to-last, and so on.

Why? Because the usual way of learning the verses sequentially is enormously dispiriting. You struggle to get the words of the first verse. After a lot of work, you begin to be comfortable with them, so you attack the second verse. But you’re back at sea. It feels like such hard work. After the second verse, you hit the wall of the third verse. You despair of learning the words at all.

Instead, learn the last verse first. Then start learning the previous verse. After you get the new verse down, you can keep on singing, but they’re words that you already know. You’re drawn along by the familiar material. You feel competent and confident. You feel good.