DEV Community: Cameron Paige

Fixing "not found: java" Mock API endpoint error

Cameron Paige — Thu, 19 Dec 2019 20:13:02 +0000

TL;DR: Download the Java SDK, then manually add the path to your environment variables.

"My middle name is Edge Case," I joked, my hand the only one raised in a room of about 100 people. At that moment, I was the only person still unable to get amplify mock api to work on the command line.

The problem? No java:

Easy fix. I found what I thought would be the right npm package and blithely hit Enter.

I got back a wall of error messages, mostly having to do with gyp missing Python:

Thankfully, somebody nearby was having a similar issue and had just solved it by downloading the Java SDK directly from Oracle.

I grabbed the Windows version, installed it, and ran amplify mock api again. Again, it told me I had no java.

I went into Programs and checked. There it was, happily ensconced between Internet Explorer (huh?) and Killer Networking (uhm... huh?).

Maybe it was telling me I needed more coffee? I tried that. No luck.

But then something clicked. I remembered similar issue I'd ran into during boot camp (the only Windows 10 user in my class). The solution then was to manually enter the path into Environment Variables.

To try that, I went to the Control Panel\System and Security\System and clicked on Advanced system settings.

In the System Properties/Advanced panel that opened, I clicked on Environment Variables.

That took me to the panel with User and System variables, both including the option to add a new Path.

I first selected the User variables Path and clicked on Edit. That took me to the Edit environment variable panel with an option to add a new Path.

To make sure I entered the path correctly, I used the File Explorer to navigate into the bin folder for Java, then right clicked on the address to copy it.

I copied and pasted it into both User and System Path variables, and clicked OK.

After that, I kept clicking OK until I was out of the Control Panel. Then, for the changes to register with the CLI, I had to close and reopen it again. Finally, I ran amplify mock api one more time...

It worked!

And so, at long last, I could carry on with the workshop, building real-time offline-ready applications with React, GraphQL & AWS AppSync.

Testing GraphQL Schema Without Data

Cameron Paige — Wed, 06 Nov 2019 07:28:21 +0000

"Cannot" is not in my vocabulary. So when I couldn't get GraphQL to work the way the tutorial I was following promised it would, I got a little bit... obsessed.

So it's not much of a surprise that now, just a couple of months since the end of the bootcamp, I find myself in a hands-on two-day GraphQL workshop.

Apart from the expected, what I learned today was:

that nobody else in the room had attempted using GraphQL with both Apollo and Prisma. (So maybe I should cut myself some slack there.)
that you can and should put comments in your schema.graphql file. (Something for another post.) And finally,
that there's a way (not mentioned in the GraphQL spec*) to test the schema without creating a dedicated .json file or fetching actual data from anywhere else.

Here's how:

Set up your index.js to require apollo-server only**, and write your schema directly below. In the picture below, we were working on a simple schema for coffee orders at a cafe:

Then, below your schema and resolvers, set up the server to use mock data for all your types:

If you run npm start now, you should be able to test your schema locally in the GraphQL Playground, with dummy variables substituted for actual data.

In the below example, I ran the allFoodItems query asking for name (specified as the scalar type String in the schema) and price (scalar type Float), and got a valid response (textual data for name and a signed double-precision fractional value for price):

And if you do have some of the data already available, you can avoid it being overwritten with mock values by adding mockEntireSchema: false to the server:

*I'd know. I always read the docs.

**I'm assuming that you're familiar with Node.js and have installed the necessary packages (apollo-server, graphql, and nodemon) already.

What's the point of pseudo-coding anyway?

Cameron Paige — Wed, 16 Oct 2019 17:04:20 +0000

One of the first assignments we were given during coding boot camp was to write out the instructions for making a PB&J sandwich. No code, just the steps.

"But WHY?," I asked (always the trouble-maker).

Because it would help us understand how fastidious computers were when it came to incomplete or ambiguous instructions, the reply went. And it was good practice to break a task most of us assumed to be exceedingly simple into its component parts.

At the time, I figured that meant I could ignore pseudo-coding if in my mind I already had a clear picture of what I wanted to build, and how.

I was wrong.

Also, hubris is a terrible, terrible drug.

Here's what I'd learned about the importance of pseudo-coding in the three short months of building progressively more complicated apps:

It helps you understand what it is you're actually trying to accomplish. Before writing a single line of code, you should have the equivalent of a movie's tagline for your app.
Breaking it down into its component parts is just the first step. The end goal should be to simplify, simplify, simplify. Can you bundle the logic for some steps into a single function? Can you further break down others, so you don't slip into the nesting hell of if statements conditional on other if statements conditional on other ifs? Can you arrange your logic in such a way that, should a step become redundant later on, it can be easily removed? Pseudo-coding is where you figure those things out. (Something, something, global variables suck.)
Clean code is fast code. It's also easier to maintain. If you don't focus on it in pseudo-coding, sooner or later you'll be refactoring your code instead (cleaning it up once it's written). Pseudo-code the heck out of that bad boy, and you'll be thanking yourself later.
Other people will thank you, too. Clean code is easier to read, and easier to build upon. Plus, keeping some of your pseudo-code as comments is a neat way of explaining your thought process to anyone who might want to use/improve your code (and to yourself later on, once you've forgotten why you decided to do something a certain way that now seems to make little sense--and that's okay, you've probably learned a lot since).
With good pseudo-code, you're 75% there to good documentation. Good documentation is king. It's how others decide how useful your app might be, and how to implement it for their needs. Get that right, and your stuff will be far more likely to get cloned. Which is how you become GitHub-popular. (Which is the best kind of popular, obviously. Now go write that darn README.)