If you’re not averse through trawling through threads on GitHub issues, this is a concise list on how to address GitHub’s vulnerability warnings in your code repository. You will see a yellow-coloured warning box if one has been detected in your package-lock.json file.
Look at the package listed at the top of the tree – json-serverin this case. Hoek is a subdependency to it via request, so the latest (or, updated) version of request would solve this issue.
If you run the first command again, you either will see the updated version of hoek or it won’t show up at all. The latter case means that it was dropped in the latest version of json-server.
There you go! May it save someone hours of pain and Googling…
I’ll write about the whole weekend in one single post because I now have two new email subscribers! Thank you, it means a lot…
This weekend was about staying in the discomfort and coming out the other side.
Coding
WordPress Development
And the other side is really sublime, calm, and beautiful. I had been procrastinating on a large coding project for a while now. It was scary and seemed insurmountable. I did a little bit every now and then, but I thought that I could get it done in one major marathon-session. That never happened.
So, this weekend over two sessions, I got the project done. It’s for a WordPress theme and plugin for a non-profit organization, so that their members across the world can set up a new website with information pre-populated from a centralized store.
It was good to be writing PHP again. The plugin and theme architectures take a while to get used to, but I’m impressed by what I can do with the API.
Custom PHP Application
Last year, I started coding a basic web application so that people at my church can digitalize the readings used in our liturgical services. A few weeks ago, the main user told me that he needs the link to the app. So, as I was about to re-send him the link, I discovered that there were some bugs in the app. (Read: the app didn’t work.)
I understand fully now why we have code reviews, pull requests, and documentation. The code made absolutelyno sense to me. It could only speak to my state of mind (frazzled) last year.
An opportune time to bring in unit testing, I went straight to where the main bug was and see how I could fix it. It got messy. I installed and configured to use PHPUnit with phpunit-watcher. The lion share of my time was getting the unit tests to reference the code and play nicely with Composer’s autoloading.
When it finally did work.. I realized that this function was doing too much. Writing the unit test compelled to refactor it to this. It still needs more work, but the process taught me a lot.
Midsummer in Sweden
It was a delightful and beautiful time, watching the raising of the Midsummer pole and families dancing around.
This is a little late, but better late than giving up.
Yesterday was hard. I spent the whole day, trying to get a testing stack going with Mocha, Chai, and AngularJS. It didn’t work, so I switched to Karma, Chai, and AngularJS. It kinda worked, but not entirely. So I switched to Jasmine. Still no cigar.
It was frustrating and a little demoralizing. But, I’ll try again on Monday.
The most striking part about MPJ’s series on unit testing is his biting and hilarious incarnating and characterization of the three most familiar voices in many developer’s minds: the anxious, the judge, and the over-engineer. Just watch one of the videos. Those names are my own, by the way. (Challenge: figure out which voice is which name I’ve given it!). Developing this further, I like to call them the Office of Sabotage. I actually thought of Amanda Palmer’s “fraud police” as I watched MPJ’s video for the first time.
I really could engage with the anxious voice today as I hunkered down to write some tests for a feature I’m pretty much done with. Yeah, I know, real TDD would have entailed to do it first! Baby steps, bro…
It wasn’t easy and felt clumsy as I tried to write the first suite. I wanted to start out with writing the tests straight in the testrunner (I’m starting out with mocha right now), but I had no idea how to start. Watching someone code doesn’t always translate to doing it myself. So, I took a step back and started thinking about the test cases by writing them in the same JavaScript file I wanted to test.
This became easier. I could see the code I was testing and it made it easier to work backwards.
Context: I’m writing tests for a feature that sends text messages using our internal system. There are three components:
the front end controller
the front end factory that calls the API controller
and, the API controller that consumes the back-end endpoint
As I ignored the Office of Sabotage’s attempts to… erm… sabotage me, a couple things occurred to me:
We just assume that the API controller will always receive the POST parameters, there are no checks at all. Something I should cater for in a test…
The error handling is a little clunky and not harmonized. It almost feels too brittle. Something to be dealt with in a test and maybe reworked in the refactor!
Today was just day 1. Tomorrow was a new day. When I got stuck, I fired up the video and just coded along.
One of my goals at work for the past month has teen driving efforts to improve our internal documentation for front-end developers. It would have been easier undoubtedly to just rant about it at meetings and talk about grandiose projects. I chose rather to do something about it in my own work.
Pull requests. I used to just put a descriptive title and leave the description empty, sometimes linking to the original issue. A call-to-action came from my coworker, who asked me for a brief summary of changes so that it’s easier for him to understand what he was about to review. So, I put in some screen shots of any UI/UX changes, a few lines about background, something about the context for the pull request, and finally a short list of the main changes. In the last couple of weeks, I’ve started also adding links to any relevant documentation I wrote, such as backend API endpoints or anything in our product wiki.
Internal documentation. We use a popular open-source system to house our internal front-end documentation. So, I’ve made it a part of my workflow to document any backend API endpoints in our system. That way, some developer won’t curse my name and the day I discovered programming when they have to maintain or debug my code.
How-tos and repo documentation. Taking my coworker’s request further, I expanded any developer documentation that lives in the repository. This is usually either how to get started or how to implement a new feature. The effort spent on this (and README.md in tow) will hopefully mean that other developers will find it easier to get going with the codebase.
Over the last couple of weeks, I have been working on a project to make Kivra’s web app ready for other languages than Swedish. It’s been a great deal of manual work, going through the codebase and moving strings to our copy repository.
This involved a lot of cross-checking and checking that the strings are being used or not. After a little while of using find/replace in Atom, I realized that this was going to take a long time.
So, I put together a little gist. That gist turned into a simple repo that I whipped together.
After customizing the repo with some tooling and npm options, it seemed like a good idea to generalize this into a boilerplate that I can reuse for other support systems or for my own projects.
I started listening to the Longform Podcast today and I noticed that they had this section underneath the player.
It’s similar, in functionality, to what you can do on YouTube by linking to specific points in the video, but it takes it further by providing direct links. It’s footnotes for the Web and I think it’s an ingenious way to help a listener focus on the podcast.
I’ll be starting this challenge tomorrow (Wednesday). I must admit that I feel a certain amount of professional shame by doing it, but there’s a conjoined sense of need to do so, too.
I’m at an uncomfortable juncture in my professional life as a developer. I have a whole lot of years of experience, but I look at job descriptions and I feel like that experience don’t align with them. It’s like that dream of showing up naked at your final high school exam, but you’re awake and it’s not a dream.
I didn’t make the right choices over the last 6 years in staying current with the latest technologies and picking the companies that would have ensured the right development of my craft. It’s uncomfortable and unavoidable.
So, doing this challenge for 100 days, along with working on my own app projects, is a way to get back on track.
Been in my situation? Mentored or known someone who has? I’d love to hear your pick-me-uppers in the comments!
EQT Ventures team are looking for digitally disruptive products from software companies.
Startups will benefit from strong tech team and postfunding support.
Team is more important than product in early stages of startup.
Together is EQT’s match-making service for startups and investors.
The team’s favorite words during pitches:
AI, machine learning, traction, product, market, metric positive unit metrics, demo, customers, I’m too busy to meet you guys
… Least favorite words:
Exit strategy, we’ve outsourced dev, strategy, constant use of I, overusing words that you dont understand
The pitches
Glance – simplify your data the autopilot for your business
Thoughts from investors, mid-pitch: “put yourself in customers shoes, good outline of problem, there are a hundred of these solutions out there,put data in context”
Good solid pitch, good touches, USP is slack bot and alexa skill, confident speaker
Happy Tails – connecting dog lovers
520 million dogs registered worldwide
2.2million active users for 2020
Fullstack team, two apps released, looking for developers
investor brain: “what is the size of the market? are those actual dog names? what part of the market do you want to start?”
Tyler: “you never know what the investor is looking at in your presentation“
energy and passion is needed in the product
Lunar Way – banking without the license
Danish company, 9 months old
Banking as a commodity
Fb bot inside Messenger, nifty
Investor brain thoughts: “primary or secondary bank for your customers?”
I was searching for Twitter clients for the commandline the other day and I found Rainbowstream. It’s an excellent tool; this is some serious software right here. You can view images. Images! Images on the CLI…
