This is perfectly fine in a development environment, where you have no concern for hackers trying to manipulate sessions. However, when you deploy your site, if this key is publicly available anywhere (like github) then hackers would have the ability to use that key to create their own session cookies with valid signatures, without having to get them from your server. That means, among other potential security concerns, they could set their own data into the session – which is often used for user authentication. You don’t want people to be able to set whatever user id they want in their session, because that allows them to bypass the login and pretend to be anyone they want!

Therefore, any time you deploy a Flask app using sessions, you need a way to hide the session key. While there are various ways to do this, my preference is to use the python-dotenv package. Here are the steps:

1. Run pipenv install python-dotenv
2. In your .gitignore file at the top level of the project, add a line saying .env
3. Run python -c 'import secrets; print(secrets.token_hex())' in your terminal, and copy the result. This will be your secret key!
4. Create a file called .env in your flask server directory
5. In that file, put SECRET_KEY= and then paste the key you copied from the terminal. No spaces or quotes necessary. An example may look like SECRET_KEY=6050fb1f5f3d35b14484718c447b1424375a6bbd39150701c0ffb5db506eadb2
6. In whichever file app.secret_key is being set (could likely be app.py or config.py) add from os import environ and from dotenv import load_dotenv
7. Before your secret key is set, add this line load_dotenv('.env')
8. Finally, change the original line that was setting the secret key to app.secret_key = environ.get('SECRET_KEY')

When you start your server up, it will now load variables from the .env file into your environment, so that last line can pull the value out and use it for the secret_key every time! The only problem remaining is that usually when you deploy your application, you’ll be doing so with git – which is ignoring the .env file. Wherever you’re hosting your site, they will have other ways to set environment files though – either through running some commands in a terminal – or very often they have a place on their site allowing you to do some server configuration. All you need to do is set up a key called SECRET_KEY with a secret key value. It’s probably fine to use the same one in your .env file, but there’s no particular reason they need to be the same in production, and often it’s probably a better idea to generate a new one for the production server to use.

Note
If collaborating with others on a git repo, only 1 person needs to do all these steps – except for the creation of the .env file and setting the SECRET_KEY value in that file. Each person will have to make their own. It doesn’t matter if you all use the same key or not because your servers and session cookies will all be independent of each other during development anyway. Also – when other people do pull these changes – they will need to re-run pipenv install in order to get the new dependency that was added.

Final Note
As you were following along you may have intuited that this technique can be used for other secret keys as well – like a 3rd party API private key. That’s right! All you have to do is add more lines to your .env file with the same sort of syntax as before, just different key names. Then in your application, you can use environ.get('WHATEVER_KEY_YOU_WANT') to access the value stored there. Similarly, you’d need to set up an environment variable wherever you deploy, using their settings or whatever method they recommend.

The post Securing Your Session Key in Flask appeared first on Morgan VanYperen.

All you need, in order to use command line arguments in Node, is process.argv. That is an array, and it’s really important to remember that the first 2 elements will have nothing to do with your elements! They actually can differ/depend on your machine, and where the file is located on your hard drive. They can be useful in certain contexts, but when we talk about CLI arguments, we are talking about every element that comes after those 2. Often, you can call process.argv.shift() twice, to get rid of those, and you’re left with just an array of elements in process.argv. Then you can do as you please with those arguments within the program!

This sort of thing is very helpful because it allows you to dynamically give values to the program without having to save them into any files anywhere. You simply state the values when you execute the program. If you have a long list of arguments you want to supply, it of course makes sense to include those in a file or database, which is then supplied as an argument, or hard-coded for the program to reference specifically – but that’s a discussion for another day! I’m still in early stages of learning node, and I am ultimately focused on using it in the context of web server functionality. This is just a neat thing I learned, that may come in handy sometime!

The post Node Arguments appeared first on Morgan VanYperen.

They explain the change very well here. Basically, instead of putting everything into brackets as an array with commas between elements, you can now just wrap it all in what appears to be an html tag, indicating it’s a fragment. Basically, syntax is almost exactly like it was before fragments existed, but it’s not an extra div, or whatever you chose to use in the past. They have a few ways to indicate it’s a fragment, but my favorite is simply <> putting things within blank tags, like this </>.

This is really interesting to me, because while I haven’t looked into how exactly they made this work, I’m pretty sure it works about the same way as when they supported arrays – they just abstracted away a lot of the code you need to write to indicate how the fragment should be put together. In any case, I like it a lot. While it’s not anything groundbreaking, it just feels right. It’s the way things should work. So to you React devs at Facebook who definitely read my blog (lol), I am proud of you. Thanks for all you do!

The post React Just Got Better (Again) appeared first on Morgan VanYperen.

One thing that bugged me a bit when learning React, was that when you’re writing JSX, you can’t simply return a set of elements. For example, when writing html, the following sort of structure might be typical to see within the body of a document:

<h1>Title</h1>
<h4>Subtitle</h4>
<p>Some text</p>
<p>More text</p>
<img src="image.jpeg" alt="image description" />
<p>Even more text</p>

So when you’re writing a component, and want it to spit that out, it seems intuitive to just create those tags, and write it as shown above. But you weren’t allowed to do that! You had to wrap it all into a div, or span, or some kind of package. That’s very trivial to do, but at the same time, it’s annoying! I don’t necessarily want to enclose a bunch of stuff into otherwise unnecessary tags. It makes things more messy than they should be in the end, and there’s often no good reason for elements to be wrapped like that.

Thankfully, we can now return fragments! Simply wrap the JSX in brackets, and return an array of elements. So instead of throwing it all into a div, which seems more like a workaround to force it to all be technically one element, you simply add some brackets, and place commas between the arrays, indicating that you want to return each of those elements – the actual stuff you want.

The tricky thing right now is, you get a console warning, unless you assign each element a key. This has to do with how React handles arrays, and what it needs in order to identify changes or removals. For fragments in particular, it actually shouldn’t matter, but the warning will still appear unless keys are added. This isn’t so convenient, but I still like where it’s going – and the react developers said they’ll add a special fragment syntax to JSX so it doesn’t require keys. I’m looking forward to that!

The post My Favorite React 16 Change appeared first on Morgan VanYperen.

I love having automated testing to run as I write code, so I can pass the tests, and check off the boxes. Who doesn’t?! The hard part is having the discipline and the know-how to write those tests in the first place.

It’s been a very long time since I’ve programmed in Java at all – long before ever thought about automated testing – or even knew about Test Driven Development as a concept. So it took me some time to learn about junit, and how to write unit tests in Java.

This github page has a very nice, succinct example of how to test a basic class in Java. It was actually extremely helpful to look at and emulate that pattern. While my tests probably could be better in a lot of ways, I was able to get them working properly, and then write all the code I needed in order to pass them. I really look forward to getting feedback on this challenge, because I want to get better and faster at writing good tests. It will make me a much better and disciplined developer!

The post Java Challenge appeared first on Morgan VanYperen.

The problem is, it can take a lot of work to set this sort of thing up. It’s definitely not a standard practice for WordPress users. I found this post, which has tips on getting started. It has a lot of valuable info, but it will only get you so far. There are a lot of tricky things that can come up, like figuring out the routing of pages – especially if you want to render javascript server-side – and authentication within the front-end application. The purpose of this project is to create a starter kit for developers, so they can download this, run a few commands, and be up and running with a headless WordPress + React setup. The hope is that these tricky problems will be solved, and you can focus more purely on designing the front-end, and putting together the WordPress back-end, without having to worry too much about how they connect.

So when I came across the project, some of these problems had already been solved on a basic level – however page routing and authentication are still not set up. That’s what I’m trying to help with now. It’s set up to use next.js, which I was not yet familiar with, and have been learning. As I learned that, I realized in order to dynamically generate pages and posts, it’s going to be a good idea for us to add Express to the project – something else I haven’t learned to use yet! However, I’ve been reading, and learning about it.

At this point, I’ve been able to add Express, and create a new route for posts. I created a route that looks like /post/:post_slug: which will dynamically handle links to individual posts, and then be able to fetch the post info from the server. It’s totally up to the developer to actually design how that data will be displayed, but it’s nice to have a boiler-plate that will do the basics for you. Talking with the project owner, we decided we want to make the routes mimic the permalink structure the WordPress back-end is set to use, but for now we just want to set up workable routes period, and then we can iteratively make progress to improve the routing structure, and make the front-end and back-end routing congruent. This has been a really fun, and productive learning experience!

The post Headless WordPress appeared first on Morgan VanYperen.

The challenges themselves were very easy to solve. The first one was a slightly modified FizzBuzz challenge in Haskell, and the second one was spotting palindromes, and sorting text, in each of the other 3 languages.

One thing that stuck out to me was the differences/similarities of taking a file path as a command line argument in Rust, Python, and Swift.

In Rust, you need std::env, std::fs::File, and std::fs::BufReader. Then you can grab your arguments and put them into an array, and then select the path from the array, open the file, and read it, like this:

let args: Vec<_> = env::args().collect();
let filepath = &args[1];
let f = File::open(filepath).unwrap();
let file = BufReader::new(&f);

In Python you only need to import sys, and you can do the following:

filepath = sys.argv[1]
with open(filepath) as fp:
    for num, line in enumerate(fp):

Then under that, you can say what you want to do for each line in that file. I implemented the same behavior in Rust, but took more code than I showed in the above example. In Python, it’s much simpler, so it’s included here.

Finally, in Swift, it’s somewhere in between. I did the following to collect the argument I wanted:

private let arguments: [String]

public init(arguments: [String] = CommandLine.arguments) { 
    self.arguments = arguments
}

Then within a public func, I had this:

let fileName = arguments[1]
    do {
        let contents = try NSString(contentsOfFile: fileName,
            encoding: String.Encoding.ascii.rawValue)
            
            contents.enumerateLines({ (line, stop) -> () in
                *CODE FOR EACH LINE HERE*
         })
        }

It took a bit of time to figure out the ins and outs of how to do this in each language, but lucky for me, reading individual lines from a file is pretty commonly done in all languages. I was able to read a lot of explanations on how other people have done it, and why they did it that way. No one I saw was trying to do the same thing I was, but reading lines from a file can be pretty universal! I’m glad for all the great documentation online – especially when learning to use a new programming language.

The post Haskell, Rust, Python, Swift appeared first on Morgan VanYperen.

There are a lot of good reasons to read the issues. Unless you’re an avid user of the software being developed, or are already pretty invested in it, you probably have no idea where to start, as far as contributing. The issues are often going to frame nicely what people want to have happen, or what bugs need to be fixed, and can often even give you a better vision of the project overall – where it is now – and where people want it to be.

Another reason is, there may be bugs to be fixed, or features to be added, that people have already discussed in depth, or recently volunteered to fix. Sometimes people volunteer, and never get around to things, but it’s still good to have an idea so you don’t do a bunch of work – only to find that it’s redundant by the time you can submit a pull request. Sometimes issues are flagged, asking for volunteers or suggestions.

One of the other great reasons to read issues is that it can be the easiest way to start contributing! Whether you create an issue on your own, or reply to existing one’s, you can often provide helpful suggestions, or ask questions that help narrow down the path for next steps in development. I’m learning more and more that software development is often not really specifically about code. A lot of it is decision-making and collaboration.

For people looking into contributing to open source – it often makes no sense to “barge” into a project and throw code at it before you really know what’s going on. Get involved in the conversation! If the Issues tab is dead, you can still glean info from the readme, or contact the owner of the repository, or active contributors – or create an issue yourself! I’m enjoying learning more about open source development, and will write more about it soon.

The post Contributing to Open Source Pt 2 appeared first on Morgan VanYperen.

In addition to trying to generally improve the notes around my code, I also of course have to learn to code better. The project I found, that I’m working on contributing to, involves combining React and WordPress together in a pretty unique way. I have an understanding of React, and of WordPress, but I’ve never used WordPress exclusively as an API before, and I’ve never used Next.js either. Lucky for me, there is a lot of beginner documentation out there for both – and this project is still in its infancy – so there are plenty of basic things to add!

To begin my process, I simply cloned the github repository, and followed the readme’s instructions for installing dependencies and launching the site in a local environment. Then I opened up the project in my text editor of choice (vscode right now) and looked it over. While I haven’t used Next.js before, everything for the front-end looked pretty familiar and intuitive based on my experience with React. I familiarized myself with the file structure, and where code and/or libraries were being imported and exported. The WordPress folder was of course, very familiar to me from my time working at Bluehost. Nothing new there.

As I saw how routing was working on the front-end, I knew I’d need to study more about Next.js if I want to help add components to display pages and posts. That seemed the most obvious thing to add at this point, but it was still unclear to me how to build that out. Here is where I went to learn to how Next.js works, and how I can add to the project. It’s really nice because it even has a section for creating dynamic pages – exactly what I want to be able to do when creating a custom react front-end for WordPress. Now that I have a pretty good understanding of how that works, I should be able to get started following that pattern, and document my work properly with git commit messages. The next tricky part is figuring out what urls to use to fetch the data from WordPress, and make sure the links all work properly. More on this to come.

The post Contributing to Open Source appeared first on Morgan VanYperen.

Well, if you read the title of this post, I guess it’s pretty obvious which I decided. There was no huge reason I chose to do it that way – I just figured since I was focused on developing in React, I might as well let it handle some of the logic – and I wanted to keep requests to the server simple. It’s also nice to offload calculations to be done client-side I guess, if it’s non-essential for the server to do it. I don’t think that matters much in this case though.

Anyway, having decided to process the data in React, I still had to decide when and where it made sense to do that. When someone visits the stats route, a few possibilities come to mind for where I can include the data processing logic. I can put it into the componentDidMount() function. This is where asynchronous requests often go – it allows for the page to load – while it does its thing in the background. It’s common to put a fetch there – that way the screen doesn’t hang while it waits for a server response. This isn’t a bad place for it, but something seems off. I’d have to either set up a local state that I update with the information I fetched, or I’d need to set up a new action/reducer to update my redux store with the stats I want to receive into the component as props.

Since I know I want to end up with the stats in either my local state, or better yet, my global redux state, passed down as props, it makes more sense to process my data within my mapStateToProps() function. Since I already have the infrastructure in place for fetching the test results and passing them down as props in that function, all I have to do is add some logic there that will handle the calculations and sorting of that data. Then I can just define new props there, and pass them into the component – keeping it as dumb as possible! That means I get to have a component that has all the info it needs handed to it as simple props, and all it has to do is make it pretty and display it on the page.

After talking with a few other developers about this, and showing them my code, I’m pretty confident I made the right choices on this. Something that was interesting to me was that in a few cases, it didn’t matter that much what choice I made – it was more a matter of convenience, or preference. However, I think it’s still important to be thoughtful about these sorts of things, in order to make my code intuitive, and to adhere to common practices wherever I can. I think this will make it easier to jump into existing projects I’m not familiar with, and set up my own projects in ways that other people will be able to collaborate on if they want.

The post Processing Data in React appeared first on Morgan VanYperen.