JSON Feed Validator
Use this validator to check if your JSON is valid and visible to our server.
For more info on this API, check out the specification.
slug key is required.Array
(
[version] => https://jsonfeed.org/version/1
[title] => JWITHY
[description] => Feed for JWITHY
[home_page_url] => https://www.jwithy.com
[feed_url] => https://www.jwithy.com/jsonfeed.json
[items] => Array
(
[0] => Array
(
[id] => https://www.jwithy.com/promising-design-patterns
[slug] => promising-design-patterns
[title] => Promising Design Patterns
[summary] => I talked to someone this evening about what I know and what I don’t know as far as web dev, React, JavaScript, and the like. And I had to admit a
[content_html] => I talked to someone this evening about what I know and what I don’t know as far as web dev, React, JavaScript, and the like.
And I had to admit a couple of things, right then and there:
- I only have a vague sense of what promises are (in JavaScript! in life, I’m good at keeping them).
- I can visualize what algorithms and design patterns are, but I have no idea if I know any of them offhand.
So I figured: why not learn something tonight?
And then I can post it! Bonus!
Promises
The thing that I knew, in the moment (probably due to the name? It’s right there on the tin): promises are a way to deal with asynchronicity.
In plain english: Once this other thing is done, then do this thing.
In fact, it literally uses then to make the promise. What could be more readable?
This isn’t the only way to do this (see also: callbacks), but it does remove some complexity, in favor of more readable code.
On that linked example, I feel like the “single-use guarantee” portion is super important:
A promise only ever has one of three states at any given time:
- pending
- fulfilled (resolved)
- rejected (error)
A pending promise can only ever lead to either a fulfilled state or a rejected state once and only once, which can avoid some pretty complex error scenarios.
For the next post in that linked tutorial the author shows how to use promises in order to implement the fetch() api. It makes so much sense, and is so readable:
fetch(this.getApiUrl())
.then(resp => resp.json())
.then(resp => {
const currentTime = resp.dateString;
this.setState({currentTime})
})
Even for someone who’s new to Promises, this makes so much sense. Give me the response, turn it into JSON, and use it to set the current time.
Woop! We just learned about promises.
As far as algorithms and design patterns? Those are less of a quick study. I did, however, find a pretty good React-oriented design patters site here:
I even saw some that I use all the time, like the spread operator in JSX and Style Components, or have learned about already, like Event Switches. Some of this feels like “unknown knowns,” as it were.
I’ve definitely got some more resources to add the list now — I’m glad I had this convo today, and took the opportunity to learn a bit more. Bit by bit, bird by bird. That’s all we can do!
[date_published] => 2019-11-14T00:00:00-08:00
[url] => https://www.jwithy.com/promising-design-patterns
)
[1] => Array
(
[id] => https://www.jwithy.com/process
[slug] => process
[title] => Process
[summary] => I’m definitely a visual thinker/learner (close second to audio learning style), and I also love to map a thing out ahead of time so I don’t have to
[image] => https://www.jwithy.comhttps://cdn.blot.im/blog_03baca9562d34d128abe1318c3d12c5a/_thumbnails/ef0dc2e7-2961-4248-93d3-21a036319abe/large.jpg
[content_html] => I’m definitely a visual thinker/learner (close second to audio learning style), and I also love to map a thing out ahead of time so I don’t have to track it in my brain.
Sometimes that means that if I’m breaking things down into components that I make some wireframe-y sketches! to Here’s a couple of examples of how that looks, from a thing I worked on this weekend:
Bonus: I get to use my fancy fountain pens!
[date_published] => 2019-06-10T00:00:00-07:00
[url] => https://www.jwithy.com/process
)
[2] => Array
(
[id] => https://www.jwithy.com/whoa-imagemagick
[slug] => whoa-imagemagick
[title] => Whoa ImageMagick!
[summary] => Holy whoa this is cool: by using ImageMagick’s command line interface, you can combine images using terminal commands like:
convert +append a.png
[content_html] => Holy whoa this is cool: by using ImageMagick’s command line interface, you can combine images using terminal commands like:
convert +append a.png b.jpg c.tif
This is super cool if you don’t feel like fussing a ton with Preview.app, or worse, launching Photoshop, etc., OR if you need to convert to a different image type (note the different extensions, above).
I used it today becaue I had a few screenshots I wanted to combine and markup for posting in an pull request. Instead of having to do all that manually, I did this:
convert +append form1.png form2.png form3.png form-all.png
…and then marked up the new image (which was form-all.png) by just by hitting spacebar in Finder and using Markup.
Easy Peasy!
I learned about ImageMagick by Googling combine three images preview mac osx which led me to StackExchange).
I installed it with brew install imagemagick; this led to an error message (Permission denied @ dir_s_mkdir - /usr/local/Frameworks), which was resolved by Googling the Error message, which took me here.
Just a small glimpse into the way that anything involving web dev is time consuming. 😀
Happy combining!
[date_published] => 2019-05-28T00:00:00-07:00
[url] => https://www.jwithy.com/whoa-imagemagick
)
[3] => Array
(
[id] => https://www.jwithy.com/literally-speaking
[slug] => literally-speaking
[title] => Literally Speaking
[summary] => Yesterday I put in a pull request for the framework that we use at work. It was related to an issue I’d submitted; namely, that I wanted to be able
[content_html] => Yesterday I put in a pull request for the framework that we use at work. It was related to an issue I’d submitted; namely, that I wanted to be able to send folks style guide links to specific variants of components we build.
Building this had a lot of codey type things in it:
- Thinking about how to build it took longer than building it! This happens not infrequently, but it’s definitely surprising to newer folks.
- I played a bit with regular expressions. Regex is a weird thing, but I didn’t want to have spaces in URLs, since those can still cause problems. A bit of googling found me the expression I needed, but I also had to fully understand the JavaScript in order to do it.
- JavaScript! I’m working on learning a lot more JS; I think it’s a case of “I know more than I think I do,” but also, it took me a minute to figure out how to do this:
// for permalinks to examples
const exampleName = example.name;
const exampleNameNoSpace = exampleName.replace(/\s+/g, '');
const exampleLink = `#${exampleNameNoSpace}`;
However, I did it!
You see, when you look up examples for using these sorts of expressions, programmers like to use variables (like str for string) that feel like they mean more than they do. So many examples used str.replace(/\s+/g that I thought it meant something important. Nope! This was just convention, used by many folks, but not necessary.
And hey, it worked!
One of the main things I had to figure out is how .jsx — combined with the linting we use — would want me to combine the # needed for an anchor link on the same page with the exampleNameNoSpace variable I’d created above it.
These are “template literals,” and though I could have concatenated the two parts, ESLint wasn’t having it. The cool thing is that the linter’s warning taught me a new thing I needed to know.
So yeah! That’s what I learned yesterday. How bout you?
[date_published] => 2019-01-31T00:00:00-08:00
[url] => https://www.jwithy.com/literally-speaking
)
[4] => Array
(
[id] => https://www.jwithy.com/hello-world
[slug] => hello-world
[title] => Hello, World!
[summary] => This thing looks pretty swell. Let’s see how it goes!
[content_html] => This thing looks pretty swell. Let’s see how it goes!
[date_published] => 2017-12-27T09:00:35-08:00
[url] => https://www.jwithy.com/hello-world
)
)
)