J7:["$","@8",null,{"children":["$","@9",null,{"children":["$","@a",null,{"children":["$","@b",null,{"posts":[{"raw":"---\ntitle: My Experience at Developer Week 2022\ndesc: A summary on the hackathon experience and project.\ndate: 2022-02-15\ncategory: misc\ntags: [hackathons]\ncover: \"/blog-covers/dev-week.png\"\n---\n\nOn January 24th, my good friend [Yannis Panagis](https://yannispanagis.com/) and I entered the [Developer Week 2022 Hackathon](https://developerweek-2022-hackathon.devpost.com/). Since last August, Yannis and I have been hacking together and always find hackathons a great way to challenge ourselves.\nIn our day jobs, it's impossible to reach our full creative potential all of the time. As engineers, we can be slowed down by politics, design constraints, legal requirements, 100% test code coverage, logic that won't work, other teams, and the list goes on.\n\nFor me, hackathons provide a way to get out of those situations and flex those creative muscles. Remind yourself that when there's nothing in the way, you can be a creative machine and Developer Week 2022 seemed like an excellent opportunity to do just that. More specifically, the Symbl.ai + Agora challenge piqued our interest as we had never experimented with WebRTC before. The exact brief:\n\n\n Combine Agora's rich interactive experience APIs with Symbl.ai's conversation\n intelligence (AI that understands natural human conversations) to build a more\n enhanced and smarter conversation experience for any use case of your choice.\n\n\n## The Idea\n\nWith every hack, Yannis and I try to keep it personal. We feel that if we are invested in the problem statement, the project will be more interesting to work on. So we asked ourselves - \"Where in tech can we make conversations smarter?\". One thing almost immediately came to mind - interviews.\n\n\n\nAs web developers, we've been through many tech interviews, and they can be frustrating - especially when those interviews don't even have someone else on the other side! We've all paid our dues with Hackerrank and Leetcode for the technical part of the process, but with little feedback and no practice alternatives, there was never a safe space to prepare for those recorded interviews once you make it past the tech tests.\n\nEven once you finally feel ready to interview, you often don't receive any feedback at all to help you improve for the next one! The problem extends both ways - the harsh truth is that interviewing well is hard.\n\n## Our Solution\n\nWe built interview toast! A trifecta of three internal tools to help you prepare, get feedback and assess.\n\n- **Interview Preparation Tool**: There are a lot of great tools out there to help you prepare for the coding part of the application process. Interviews aren't just about code, and there aren't a lot of tools out there specifically designed to help you with the conversational part of the process. By leveraging Symbl's conversation intelligence AI in our video application, InterviewToast goes beyond simple speech-to-text and provides real-time insights and extracts keywords, sentiment and conversation analytics such as talk-to-listen ratios.\n- **Interview Feedback Tool**: By sourcing questions directly from the candidate they want to practice, InterviewToast extracts quantitative and qualitative feedback on practice interview sessions to help candidates get ready to find their next dream job.\n- **Interview Assessment Tool**: Our interview tool goes beyond the practice rooms straight into the interview battlefield. InterviewToast uses Agora to provide real-time transcriptions, keyword and profanity detection, and analysis on live interviews.\n\nBut the best way to explain it is by showing it! You can try it out at [InterviewToast.com](https://interviewtoast.com).\n\n### Fun fact!\n\nThe name \"InterviewToast\" has a double meaning! Toast can be undercooked or burned, just like an interview! But [toast can also refer to the small alerts](https://ux.stackexchange.com/questions/11998/what-is-a-toast-notification) you get while using software applications.\n\n## How it was Built\n\n

\n \n \n \n \n \n \n \n \n Gatsby Functions\n

\n ),\n },\n position: { x: 350, y: 125 },\n },\n {\n type: \"output\",\n id: \"2.1\",\n data: {\n label: (\n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n Real-time API\n \n

\n ),\n },\n position: { x: 0, y: 125 },\n },\n {\n type: \"output\",\n id: \"2.2\",\n data: {\n label: (\n

\n \n \n \n \n \n \n \n \n \n WebRTC Client\n

\n ),\n },\n position: { x: 175, y: 125 },\n },\n {\n id: \"1.1\",\n type: \"input\", // input node\n data: {\n label: (\n

\n \n \n \n \n \n \n \n Gatsby.js\n

\n ),\n },\n position: { x: 150, y: 0 },\n },\n {\n id: \"1.2\",\n type: \"input\", // input node\n data: {\n label: (\n

\n \n \n \n \n \n TensorFlowJS\n

\n ),\n },\n position: { x: 350, y: 0 },\n },\n {\n id: \"3\",\n type: \"output\", // output node\n data: {\n label: (\n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n SendGrid Email\n

\n ),\n },\n position: { x: 250, y: 250 },\n },\n {\n id: \"4\",\n type: \"output\", // output node\n data: {\n label: (\n

\n \n \n \n \n \n \n Firebase\n

\n ),\n },\n position: { x: 450, y: 250 },\n },\n {\n id: \"5\",\n type: \"output\", // output node\n data: {\n label: (\n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n Async API\n

\n ),\n },\n position: { x: 50, y: 250 },\n },\n // animated edge\n { id: \"e1-2\", source: \"1.1\", target: \"2\", animated: true },\n { id: \"e1-2\", source: \"1.1\", target: \"2.1\", animated: true },\n { id: \"e1-2\", source: \"1.1\", target: \"2.2\", animated: true },\n { id: \"e1-2\", source: \"1.2\", target: \"2\", animated: true },\n { id: \"e2-3\", source: \"2\", target: \"3\", animated: true },\n { id: \"e2-3\", source: \"2\", target: \"4\", animated: true },\n { id: \"e2-3\", source: \"2\", target: \"5\", animated: true },\n ]}\n />\n\n\nInterviewToast was built with:\n\n- [Symbl.ai](https://symbl.ai/)'s for sentiment analysis, topic extraction, conversation analytics, entity and intent recognition, and real-time insights APIs.\n- [Agora.io](https://www.agora.io/) to enable vivid voice and video calling directly in the browser for real-time interviewer-candidate engagement\n- [GatsbyJS](https://www.gatsbyjs.com/) as our blazing-fast React framework for performance, scalability, security and accessibility\n- [Gatsby Cloud Functions](https://www.gatsbyjs.com/products/cloud/functions/) to bring an entire backend to InterviewToast - without managing a backend\n- [Firebase](https://firebase.google.com/) to enable user accounts and SSO.\n- [TensorFlowJS MoveNet](https://blog.tensorflow.org/2021/05/next-generation-pose-detection-with-movenet-and-tensorflowjs.html) model for body keypoint detection to evaluate candidates posture and slouching in real-time for practice sessions\n\n## Challenges\n\nWebRTC is something that scared me; I have been avoiding it until now. This hackathon gave me a chance to face that fear. While I am sure that our WebRTC integration is not perfect, I have learnt how to implement it and, now feeling a little more confident, I can't wait to work with it again.\n\n## Next Steps\n\nAlthough this hackathon took place over two weeks, there were still a lot of features that we would have loved to implement that we did not have time for. The following is a list of some of the extensions we would like to implement next:\n\n- **Stripe Integration**: We can't monetise the site without integrating a payment API!\n- **Pre-call Tests** for Audio and Video: Verify whether the internet quality is good enough for the interview.\n- **Better Stats**: We love data visualisation! We would love to include interactive charts that drill down into the data (with D3!).\n\nFor more information on the product, read the Devpost [here](https://devpost.com/software/draft-submission-dzl5pn).\n","frontMatter":{"title":"My Experience at Developer Week 2022","cover":"/blog-covers/dev-week.png","desc":"A summary on the hackathon experience and project.","date":"2022-02-15","category":"misc"},"hash":"db2db620a0970d2a6c0561b70728d580a52f3f3687275894916ead965d8dbf9fc7737213af6d672747766d58215b6b0245881dbf86ddcc4306d56c8e65c1654c","content":"\nOn January 24th, my good friend [Yannis Panagis](https://yannispanagis.com/) and I entered the [Developer Week 2022 Hackathon](https://developerweek-2022-hackathon.devpost.com/). Since last August, Yannis and I have been hacking together and always find hackathons a great way to challenge ourselves.\nIn our day jobs, it's impossible to reach our full creative potential all of the time. As engineers, we can be slowed down by politics, design constraints, legal requirements, 100% test code coverage, logic that won't work, other teams, and the list goes on.\n\nFor me, hackathons provide a way to get out of those situations and flex those creative muscles. Remind yourself that when there's nothing in the way, you can be a creative machine and Developer Week 2022 seemed like an excellent opportunity to do just that. More specifically, the Symbl.ai + Agora challenge piqued our interest as we had never experimented with WebRTC before. The exact brief:\n\n\n Combine Agora's rich interactive experience APIs with Symbl.ai's conversation\n intelligence (AI that understands natural human conversations) to build a more\n enhanced and smarter conversation experience for any use case of your choice.\n\n\n## The Idea\n\nWith every hack, Yannis and I try to keep it personal. We feel that if we are invested in the problem statement, the project will be more interesting to work on. So we asked ourselves - \"Where in tech can we make conversations smarter?\". One thing almost immediately came to mind - interviews.\n\n\n\nAs web developers, we've been through many tech interviews, and they can be frustrating - especially when those interviews don't even have someone else on the other side! We've all paid our dues with Hackerrank and Leetcode for the technical part of the process, but with little feedback and no practice alternatives, there was never a safe space to prepare for those recorded interviews once you make it past the tech tests.\n\nEven once you finally feel ready to interview, you often don't receive any feedback at all to help you improve for the next one! The problem extends both ways - the harsh truth is that interviewing well is hard.\n\n## Our Solution\n\nWe built interview toast! A trifecta of three internal tools to help you prepare, get feedback and assess.\n\n- **Interview Preparation Tool**: There are a lot of great tools out there to help you prepare for the coding part of the application process. Interviews aren't just about code, and there aren't a lot of tools out there specifically designed to help you with the conversational part of the process. By leveraging Symbl's conversation intelligence AI in our video application, InterviewToast goes beyond simple speech-to-text and provides real-time insights and extracts keywords, sentiment and conversation analytics such as talk-to-listen ratios.\n- **Interview Feedback Tool**: By sourcing questions directly from the candidate they want to practice, InterviewToast extracts quantitative and qualitative feedback on practice interview sessions to help candidates get ready to find their next dream job.\n- **Interview Assessment Tool**: Our interview tool goes beyond the practice rooms straight into the interview battlefield. InterviewToast uses Agora to provide real-time transcriptions, keyword and profanity detection, and analysis on live interviews.\n\nBut the best way to explain it is by showing it! You can try it out at [InterviewToast.com](https://interviewtoast.com).\n\n### Fun fact!\n\nThe name \"InterviewToast\" has a double meaning! Toast can be undercooked or burned, just like an interview! But [toast can also refer to the small alerts](https://ux.stackexchange.com/questions/11998/what-is-a-toast-notification) you get while using software applications.\n\n## How it was Built\n\n

\n \n \n \n \n \n \n \n \n Gatsby Functions\n

\n ),\n },\n position: { x: 350, y: 125 },\n },\n {\n type: \"output\",\n id: \"2.1\",\n data: {\n label: (\n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n Real-time API\n \n

\n ),\n },\n position: { x: 0, y: 125 },\n },\n {\n type: \"output\",\n id: \"2.2\",\n data: {\n label: (\n

\n \n \n \n \n \n \n \n \n \n WebRTC Client\n

\n ),\n },\n position: { x: 175, y: 125 },\n },\n {\n id: \"1.1\",\n type: \"input\", // input node\n data: {\n label: (\n

\n \n \n \n \n \n \n \n Gatsby.js\n

\n ),\n },\n position: { x: 150, y: 0 },\n },\n {\n id: \"1.2\",\n type: \"input\", // input node\n data: {\n label: (\n

\n \n \n \n \n \n TensorFlowJS\n

\n ),\n },\n position: { x: 350, y: 0 },\n },\n {\n id: \"3\",\n type: \"output\", // output node\n data: {\n label: (\n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n SendGrid Email\n

\n ),\n },\n position: { x: 250, y: 250 },\n },\n {\n id: \"4\",\n type: \"output\", // output node\n data: {\n label: (\n

\n \n \n \n \n \n \n Firebase\n

\n ),\n },\n position: { x: 450, y: 250 },\n },\n {\n id: \"5\",\n type: \"output\", // output node\n data: {\n label: (\n

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n Async API\n

\n \n \n \n \n \n \n \n \n Gatsby.js\n

\n ),\n },\n position: { x: 250, y: 125 },\n },\n {\n id: \"1\",\n type: \"input\", // input node\n data: { label: \"MarkDown\" },\n position: { x: 50, y: 25 },\n },\n {\n id: \"1.3\",\n type: \"input\", // input node\n data: { label: \"API\" },\n position: { x: 150, y: -50 },\n },\n {\n id: \"1.4\",\n type: \"input\", // input node\n data: { label: \"CMS\" },\n position: { x: 350, y: -50 },\n },\n {\n id: \"1.1\",\n type: \"input\", // input node\n data: { label: \"JSON\" },\n position: { x: 250, y: 25 },\n },\n {\n id: \"1.2\",\n type: \"input\", // input node\n data: { label: \"Anywhere else!\" },\n position: { x: 450, y: 25 },\n },\n {\n id: \"3\",\n type: \"output\", // output node\n data: { label: \"CSS\" },\n position: { x: 250, y: 250 },\n },\n {\n id: \"4\",\n type: \"output\", // output node\n data: { label: \"JS\" },\n position: { x: 450, y: 250 },\n },\n {\n id: \"5\",\n type: \"output\", // output node\n data: { label: \"HTML\" },\n position: { x: 50, y: 250 },\n },\n // animated edge\n { id: \"e1-2\", source: \"1\", target: \"2\", animated: true },\n { id: \"e1-2\", source: \"1.1\", target: \"2\", animated: true },\n { id: \"e1-2\", source: \"1.2\", target: \"2\", animated: true },\n { id: \"e1-2\", source: \"1.3\", target: \"2\", animated: true },\n { id: \"e1-2\", source: \"1.4\", target: \"2\", animated: true },\n { id: \"e2-3\", source: \"2\", target: \"3\", animated: true },\n { id: \"e2-3\", source: \"2\", target: \"4\", animated: true },\n { id: \"e2-3\", source: \"2\", target: \"5\", animated: true },\n ]}\n />\n\nGatsby can ingest content and data from wherever you can find it: APIs, CMSs, databases,\nlocal files. Gatsby ingests these data points into it's data layer. Once data is\npulled into Gatsby, your pages and components, both of which are built in react,\nspecify what data they want to access through GraphQL queries. Gatsby run these queries\nand supplies your templates with content. The resultant HTML, CSS and JS are then\nready to be served to your visitors.\n\nThis all happens at build time meaning its...\n\n\n\n Prerendered\n\n\n\nThis all happens at build time. Every route is prerendered and therefore is static content. When we say static content we mean that the content does not change for each visitor and its content is not dynamic. There is no computation neccessary - it always serves exactly what is stored.\n\nSometimes I find this funny because its a real blast from the past. Static sites have been around for a very long time. They are the original blueprint for any website: HTML, CSS, and JavaScript. In the 1990s, HTML was the only publishing mechanism for the web. To get content on the internet, you would have to create a static HTML file and provide them via a server exposed to the internet.\n\n\n

Blast from the Past

\n\n\nAlthough the approach is old-school - it has some real benefits that I would\nlike to run you through. While I will be focusing on GatsbyJS, most, if not\nall, of these apply to all static site generators.\n\n## Advantages of Gatsby\n\n- **Speed**: It's hard to beat the speed of sending static output. As we've already\n discussed there is no thinking or computation needed before the files are\n sent.\n- **Percieved performance**: The content becomes visible far sooner when using static site generators as you can see from this diagram.\n- **Scalability**: Gatsby is designed to scale. It's easy to add more pages and\n components to your site.\n- **Security**: Gatsby is designed to be secure. It's easy to secure your site.\n- **SEO**: Gatsby is designed to be SEO friendly. Search engine crawlers may fail to run JavaScript to render your React app. So your React app can be indexed as a blank page, which clearly doesn't help a user find you through google. This issue goes away with prerendered content.\n\nThough not always as important to the client, having a tools that your\ndevelopers find easier to use should always be considered a bonus. Using\nGatsby we can remove logic we all find pernickety like routing, progressive\nimage loading and data fetching. Documentation is also among the best that\nI've seen.\n\n\n It's also really important to remember that just because you're using a static\n site it does not mean that your site pages have to be static or any less\n interesting. This presentation deck was built in Gatsby and I'm sure you'll\n agree there is nothing boring about it.\n\n\nUp until version 4 of Gatsby these were the kind of sites that Gatsby really\nexcelled at. But in September of last year things changed.\n\nWhile Gatsby is my favourite, it is crucial to understand that it is not the\nonly React static site generator on the market. The competitor most often uttered in the same breath is Next.js.\n\n\n\nIf we look at npm downloads over the last few months, you'll see that Gatsby\nhas been consistently beaten by Next.js. Why is that?\n\n

\n \n

\n \n \n \n \n \n \n \n \n Gatsby.js\n

Blast from the Past

\n \n

\n\nWell, Next.js can deploy a static build or instead (and most often) a server.\nWhen a page is requested, this server builds that page and caches it before\nsending it to the user. This means that subsequent requests to the resource\nare faster than the first call. Which brings us on to the next point.\n\n### Sometimes Static Isn't Enough\n\nSometimes Static Builds are not enough, Server Side Rendering allows us to\ncreate better experiences paticularly for authenticated experiences.\n\n\n It should however be noted that when comparing a Next.js server to a Gatsby\n static site, the intial page load will always be faster on Gatsby.\n\n\nWithout SSR, Gatsby was losing market share. It desperatly had to adapt to\nkeep up. With the introduction of Gatsby v4, Gatsby pivoted from a static site\ngenerator to a full stack front-end framework. Introducing some great features\nlike DSG and SSR.\n\n### Hybrid Build\n\nIf you're using DSG, SSR or functions you can no longer serve up a static\nbuild as the server needs to think. So in the cases where these features are\nused, Gatsby uses node to create a server to handle requests. Hybrid builds\nare the best of both worlds - we should be using them more.
It should\nbe noted that you can still create static builds without these features if you\nwant to.\n\nGatsby wasn't the only one to change its thinking over the last year...\n\nWhile Gatsby moved into SSR & DSG, Next moved into static site generation.\nBoth frameworks now cover all bases. Both approaches have great use cases so\nit really does depend on the project.\n\n## But which one?\n\nThis might lead you to ask the question \"which one do I use?\" The answer is -\neither one is better than neither on projects that are suitable! One thing I\nwill say is that image optimisation is better in Gatsby at the moment but this\ncould change soon.\n","slug":"GatsbyOverview","filePath":"/vercel/path0/content/blog/GatsbyOverview.mdx","tableOfContents":[{"title":"Advantages of Gatsby","link":"#advantages-of-gatsby","depth":1},{"title":"Sometimes Static Isn't Enough","link":"#sometimes-static-isnt-enough","depth":2},{"title":"Hybrid Build","link":"#hybrid-build","depth":2},{"title":"But which one?","link":"#but-which-one","depth":1}]},{"raw":"---\ntitle: Dealing with Slow Weeks\ndesc: My coping mechanism for those weeks that don't seem to end - let's avoid imposter syndrome.\ndate: 2021-08-17\ncategory: misc\ntags: [health, well-being]\ncover: /blog-covers/slow.jpeg\n---\n\n## We've all been there.\n\nYou start a task you thought would be easy on Monday morning. But three days later you're still battling it. You've searched, rechecked, tested again and again but, no matter what you do, this bug, glitch or blocker just isn't going away. With every passing hour you're reminded that it still isn't done and you feel like something so small and unplanned shouldn't be holding you back. You're angry at yourself and at your code.\n\nThis is a situation that _every_ developer finds themselves in now and then. Working in our profession is like being on a rollercoaster, sometimes you're going to feel like you are working a million miles an hour and other times you going to feel like the snail at the top of this post. While one week like this can be bad enough, if you ever find yourself with a few like this in a row you can really start to doubt your own ability. What do you do? You can grit your teeth and get through it but that doesn't do anything for your confidence and it certainly doesn't help stop the same situation from popping up again. Instead, next time you're feeling like this, consider this trifecta of tips:\n\n## 1. Let It Be Known\n\nOne of the **worst** things you can do for yourself in this situation is keep it to yourself. If no one in your team is aware that you're struggling, then your team may just think you're being slow or lazy. Use the 125% rule: **If you've started a task and spent 110% of the allotted time on it and it still isn't done, notify your team.**\n\n\n Sharing with your team that you're finding things difficult does more than\n just allow them to adjust their timelines, it allows them to help and support\n you with it. Perhaps there is another engineer that you can pair with on the\n issue? Or maybe just having someone as a sound board will help you find the\n solution faster.\n\n\n## 2. Context Switch\n\nSometimes we are in the wrong frame of mind for this particular task. There are two different ways I like to context switch - Changing my active task and stepping away:\n\n### Changing my Active Task\n\nSometimes you're in the fortunate position of having lots of different stories to pick up in a sprint. While it's never good to have all of your tasks in progress at the same time, when you're struggling with one, switching to a different story might allow you to work a different part of your brain. Also, if this other task seems to be progressing faster it might help you feel better as you are seeing progression.\n\n### Stepping Away\n\nIn cases where you don't have other pieces of work that you can work on, you can still context switch by stepping back from your work for a peaceful moment. As engineers its easy to spend all day glued to your desk, sometimes removing yourself from your work environment for a quick walk around your local park can really help you feel refreshed and re-energised. I have often been in the position where I return from one of these walks and the solution to my problem is staring me in the face.\n\n## 3. Remind Yourself What You're Capable Of\n\nIf I've had a week where I feel imposter syndrome kicking in, I like to use a portion of my weekend to work on a smaller project to remind myself that I am a capable dev when left to my own devices.\n\n> Take a part of your weekend to work on a smaller project to remind yourself that you are a capable developer when there aren't any blockers.\n\nSome of the work I've had the most fun doing, has come out of these sessions. If I haven't had the chance to be creative during the week\n\n## You're not alone\n\nDo you ever get slow weeks? If so, how often? Share your answer below, responses are anonymous. By answering you might be helping someone going through a week like this to know they are not on their own.\n\n\n","frontMatter":{"title":"Dealing with Slow Weeks","cover":"/blog-covers/slow.jpeg","desc":"My coping mechanism for those weeks that don't seem to end - let's avoid imposter syndrome.","date":"2021-08-17","category":"misc"},"hash":"4c53d6dce6063ca6a2dd37eb4a42177d01d0570988e64bfe42f3304cda39dcda8bcb0d41b465ff7e035cff98eb73e389c5d9d583a28855d59085b97f81c61bf7","content":"\n## We've all been there.\n\nYou start a task you thought would be easy on Monday morning. But three days later you're still battling it. You've searched, rechecked, tested again and again but, no matter what you do, this bug, glitch or blocker just isn't going away. With every passing hour you're reminded that it still isn't done and you feel like something so small and unplanned shouldn't be holding you back. You're angry at yourself and at your code.\n\nThis is a situation that _every_ developer finds themselves in now and then. Working in our profession is like being on a rollercoaster, sometimes you're going to feel like you are working a million miles an hour and other times you going to feel like the snail at the top of this post. While one week like this can be bad enough, if you ever find yourself with a few like this in a row you can really start to doubt your own ability. What do you do? You can grit your teeth and get through it but that doesn't do anything for your confidence and it certainly doesn't help stop the same situation from popping up again. Instead, next time you're feeling like this, consider this trifecta of tips:\n\n## 1. Let It Be Known\n\nOne of the **worst** things you can do for yourself in this situation is keep it to yourself. If no one in your team is aware that you're struggling, then your team may just think you're being slow or lazy. Use the 125% rule: **If you've started a task and spent 110% of the allotted time on it and it still isn't done, notify your team.**\n\n\n Sharing with your team that you're finding things difficult does more than\n just allow them to adjust their timelines, it allows them to help and support\n you with it. Perhaps there is another engineer that you can pair with on the\n issue? Or maybe just having someone as a sound board will help you find the\n solution faster.\n\n\n## 2. Context Switch\n\nSometimes we are in the wrong frame of mind for this particular task. There are two different ways I like to context switch - Changing my active task and stepping away:\n\n### Changing my Active Task\n\nSometimes you're in the fortunate position of having lots of different stories to pick up in a sprint. While it's never good to have all of your tasks in progress at the same time, when you're struggling with one, switching to a different story might allow you to work a different part of your brain. Also, if this other task seems to be progressing faster it might help you feel better as you are seeing progression.\n\n### Stepping Away\n\nIn cases where you don't have other pieces of work that you can work on, you can still context switch by stepping back from your work for a peaceful moment. As engineers its easy to spend all day glued to your desk, sometimes removing yourself from your work environment for a quick walk around your local park can really help you feel refreshed and re-energised. I have often been in the position where I return from one of these walks and the solution to my problem is staring me in the face.\n\n## 3. Remind Yourself What You're Capable Of\n\nIf I've had a week where I feel imposter syndrome kicking in, I like to use a portion of my weekend to work on a smaller project to remind myself that I am a capable dev when left to my own devices.\n\n> Take a part of your weekend to work on a smaller project to remind yourself that you are a capable developer when there aren't any blockers.\n\nSome of the work I've had the most fun doing, has come out of these sessions. If I haven't had the chance to be creative during the week\n\n## You're not alone\n\nDo you ever get slow weeks? If so, how often? Share your answer below, responses are anonymous. By answering you might be helping someone going through a week like this to know they are not on their own.\n\n\n","slug":"SlowWeeks","filePath":"/vercel/path0/content/blog/SlowWeeks.mdx","tableOfContents":[{"title":"We've all been there.","link":"#weve-all-been-there","depth":1},{"title":"1. Let It Be Known","link":"#1-let-it-be-known","depth":1},{"title":"2. Context Switch","link":"#2-context-switch","depth":1},{"title":"Changing my Active Task","link":"#changing-my-active-task","depth":2},{"title":"Stepping Away","link":"#stepping-away","depth":2},{"title":"3. Remind Yourself What You're Capable Of","link":"#3-remind-yourself-what-youre-capable-of","depth":1},{"title":"You're not alone","link":"#youre-not-alone","depth":1}]},{"raw":"---\ntitle: Sniffing Login Requests\ndesc: How to use puppeteer to sniff requests.\ndate: 2021-04-20\ncategory: dev\ntags: [pupteer, requests]\ncover: \"/blog-covers/sniff.jpeg\"\n---\n\nI have been pondering the idea of publicising my run data in an effort to get me to run more. If its public, I can easily be held accountable. I’ve been using the Nike Run Club since 2014 and have logged just over 200 runs over that time using the app. That’s a lot of data.\n\nSadly, even in a world where GDPR is a thing, Nike has not made it possible for people to download their own run data. I think this is in an effort to keep you using their app as having access to your run data would make it too easy to switch to another service.\n\n## The (Automated?) Journey for an Access Token\nThanks to [@yasoobkhalid](https://twitter.com/yasoobkhalid) I came across this [gist](https://gist.github.com/niw/858c1ecaef89858893681e46db63db66) that explains how to hit the Nike API assuming you have a bearer token from the Nike site - they use the same auth service for both their site and the Nike Run Club app. The only problem with this process is that it requires you to go and login to Nike to get a new bearer token whenever you want to retrieve your data - Not cool. I want to be able to retrieve my data as part of my Gatsby build script every time I deploy my site and I don’t want to do this manually.\n\nTime to whip out Node and see if I can hit the Nike Auth service with my login credentials. A simple POST request to their auth service. Or not. To cut a long story short, this failed. When trying to send this post request through node I got:\n\n```HTML\n

Access Denied

\nYou don't have permission to access \"http://unite.nike.com/login?\" on this server.

Access Denied

\nYou don't have permission to access \"http://unite.nike.com/login?\" on this server.

\nReference #18.1e6cd417.1571674983.fd73639\n```\n\nNike’s website seemed to be stopping me at every turn - not surprising really. I was probably missing a cookie that was needed for the request. Then I had a bright idea. Instead of trying to hit the auth API through a POST request, I thought I would instead see if I could intercept the login post request response using puppeteer as it would technically visit the site for me. Slower but I might have better luck! The code I came up with can be seen below:\n\n\n```js\nawait page.goto(\"https://www.nike.com/gb/member/profile\", {\n waitUntil: \"networkidle0\",\n})\nconsole.log(\"👟 Navigated to Nike.com\")\nawait page.click(\".g72-menu\")\nconsole.log(\"🍔 Clicked on burger menu\")\nawait page.click(\"#MobileAccountMenuHeader\")\nconsole.log(\"💪 Clicked Login\")\nawait page.waitForSelector('input[name=\"emailAddress\"]')\nawait page.type('input[name=\"emailAddress\"]', process.env.nike_username)\nawait page.type('input[name=\"password\"]', process.env.nike_password)\nconsole.log(\"✍️ Filled In Form\")\nawait page.click(\".loginSubmit\")\nconsole.log(\"✅ Submitted Form\")\n```\n\nThis code goes through the process of logging into Nike. But we also need to listen for the response from the login request. We can do this by using puppeteer’s `page.on` method:\n\n```js\npage.on(\"response\", async response => {\n const url = response.url()\n try {\n const req = response.request()\n const orig = req.url()\n if (orig.includes(\"login\")) {\n const text = await response.text()\n const body = await JSON.parse(text)\n const status = response.status()\n console.log(\"🎉 Found login response!\")\n console.log({ orig, status, body })\n await browser.close()\n callScript(body.access_token)\n }\n } catch (err) {\n console.error(err)\n }\n })\n```\n\nThe script takes 15 seconds to run, based on my internet speed - I can live with that, especially as I am only running this script when I build with an optional flag.\n\n## A small improvement\n\nAfter further testing I managed to make it even faster by removing `waitUntil: \"networkidle0\"`. I had added this to ensure the nav had loaded but it turns out that it was also waiting for all the resources to completely load the page. Instead I could just wait for the element I wanted to click `await page.waitForSelector(\".g72-menu\")`.\n\nThis got the script run time down to 3 seconds on.a pretty average network speed. Nice.","slug":"SniffingLogin","filePath":"/vercel/path0/content/blog/SniffingLogin.mdx","tableOfContents":[{"title":"The (Automated?) Journey for an Access Token","link":"#the-automated-journey-for-an-access-token","depth":1},{"title":"A small improvement","link":"#a-small-improvement","depth":1}]},{"raw":"---\ntitle: Learnings from Book Writing\ndesc: Here are my key takeaways from my first experience being an author.\ndate: 2021-01-21\ncategory: career\ntags: [book writing]\ncover: /blog-covers/book.png\n---\n\nIn March of 2021, I was approached on LinkedIn by a publisher. They asked if I would like to write a book - the subject? Gatbsy.js. Being an author was something that immediately excited me. I never saw myself as the kind of person who would have the patience to write a book, but I like a challenge. Nine months and two hundred and twenty-five pages later, the book is complete! You can check it out here if you are interested.\n\nIt was one of the most challenging things I have ever done, and I now have a newfound appreciation for authors. Here are my key takeaways from my experience.\n\n## A good plan is vital.\n\nOne of the first documents I had to produce for the book was an outline. In this outline, I had to split my desired content into chapters with descriptions, split those chapters into headings, and work out learning objectives for the reader. There is nothing worse than looking at a blank page and not having any direction. Instead of looking at a blank document when starting a chapter, I would populate it with the headings from the outline. These headings gave me a far more precise objective of where I needed to get to within each chapter and helped the content flow between sections. This strategy is something that I will be using even outside of long-form writing. Even a quick blog post can benefit from a small plan or outline. Hopefully, you can see the difference in the quality of my content.\n\n## Don't compromise on downtime.\n\nI was writing this book while holding a full-time job. My initial thought was to use the weekends to write the book. It turns out that this negatively impacted my performance across all my work as I was constantly tired, and I had not had some dedicated time to recharge my batteries. Not to mention my partner, who I think felt neglected at times.\n\n## Get into a routine and stick to it.\n\nWhen approaching a difficult task, routine is everything. Particularly during the summer months, I didn't want to spend more time at my desk in the evenings. I started getting up an hour or two earlier than usual and used this newfound time to write the book. While it was hard at first, repeatedly sticking to this schedule, I found time I never knew I had. It also meant that I felt more awake when I got to my work day instead of just rolling out of bed at 5 to 9.\n","frontMatter":{"title":"Learnings from Book Writing","cover":"/blog-covers/book.png","desc":"Here are my key takeaways from my first experience being an author.","date":"2021-01-21","category":"career"},"hash":"54045dd3526130054fbb8c541d8304534cc33af82aaa73bd3ddb57001d3f8daa1ebe991806d0edfc4827cc8783f0d44b7e8a7c1a85557552e1052c743bb6659d","content":"\nIn March of 2021, I was approached on LinkedIn by a publisher. They asked if I would like to write a book - the subject? Gatbsy.js. Being an author was something that immediately excited me. I never saw myself as the kind of person who would have the patience to write a book, but I like a challenge. Nine months and two hundred and twenty-five pages later, the book is complete! You can check it out here if you are interested.\n\nIt was one of the most challenging things I have ever done, and I now have a newfound appreciation for authors. Here are my key takeaways from my experience.\n\n## A good plan is vital.\n\nOne of the first documents I had to produce for the book was an outline. In this outline, I had to split my desired content into chapters with descriptions, split those chapters into headings, and work out learning objectives for the reader. There is nothing worse than looking at a blank page and not having any direction. Instead of looking at a blank document when starting a chapter, I would populate it with the headings from the outline. These headings gave me a far more precise objective of where I needed to get to within each chapter and helped the content flow between sections. This strategy is something that I will be using even outside of long-form writing. Even a quick blog post can benefit from a small plan or outline. Hopefully, you can see the difference in the quality of my content.\n\n## Don't compromise on downtime.\n\nI was writing this book while holding a full-time job. My initial thought was to use the weekends to write the book. It turns out that this negatively impacted my performance across all my work as I was constantly tired, and I had not had some dedicated time to recharge my batteries. Not to mention my partner, who I think felt neglected at times.\n\n## Get into a routine and stick to it.\n\nWhen approaching a difficult task, routine is everything. Particularly during the summer months, I didn't want to spend more time at my desk in the evenings. I started getting up an hour or two earlier than usual and used this newfound time to write the book. While it was hard at first, repeatedly sticking to this schedule, I found time I never knew I had. It also meant that I felt more awake when I got to my work day instead of just rolling out of bed at 5 to 9.\n","slug":"Book-Learnings","filePath":"/vercel/path0/content/blog/Book-Learnings.mdx","tableOfContents":[{"title":"A good plan is vital.","link":"#a-good-plan-is-vital","depth":1},{"title":"Don't compromise on downtime.","link":"#dont-compromise-on-downtime","depth":1},{"title":"Get into a routine and stick to it.","link":"#get-into-a-routine-and-stick-to-it","depth":1}]}],"children":["$","@4",null,{"parallelRouterKey":"children","segmentPath":["children","(default-providers)","children","(with-nav)","children"],"hasLoading":false,"template":["$","@5",null,{}],"notFound":"Couldn't find requested presentation","notFoundStyles":[],"childProp":{"current":[[],[],["$","@c",null,{"children":["$","@4",null,{"parallelRouterKey":"children","segmentPath":["children","(default-providers)","children","(with-nav)","children","blog","children"],"hasLoading":false,"template":["$","@5",null,{}],"notFound":"Couldn't find requested resource","notFoundStyles":[],"childProp":{"current":["$","@4",null,{"parallelRouterKey":"children","segmentPath":["children","(default-providers)","children","(with-nav)","children","blog","children",["slug","dev","c"],"children"],"hasLoading":false,"template":["$","@5",null,{}],"childProp":{"current":[[],[],"@d"],"segment":""},"rootLayoutIncluded":true}],"segment":["slug","dev","c"]},"rootLayoutIncluded":true}],"params":{}}]],"segment":"blog"},"rootLayoutIncluded":true}]}]}]}]}]

Posts related to Development

A Gatsby Overview

An Overview of Gatsby.js for the Uninitiated

Sniffing Login Requests

How to use puppeteer to sniff requests.

Rethinking 404 Pages

What if your 404 page could do more?