Diéssica Gurskas

We Misunderstand Learning

2024-09-19T13:13:42+00:00

We misunderstand learning. We think learning happens as we consume information, so we insist on consumption, hoping it will make sense. Reading sparks new ideas—yet often we merely seek out validation for the ones we already have. We misunderstand learning. We cling to theory like a lifeline, as though it can stand on its own, while overlooking the experimental space where it transforms: practice. Perhaps we gamify it. (Unlearning our addictions is another matter entirely.) We escape the confusion that must linger–it slips us that lingering isn’t forever. We misunderstand learning. Through edutainment, we satisfy the illusion of smooth progress, estimated reading times, chapter after chapter. True learning is too disjointed, unpredictable, and fraught with setbacks. We obsess over minimising gaps between repetitions, but are these gaps learning breaks, or learning itself? I recall the first time I picked up a guitar: my fingers aching to stretch, shredding like crazy against the strings. The morning after, I played the chord—not through conscious effort or passion, but because my fingers developed dexterity and calluses overnight. We misunderstand learning. Technique matters, yes, but some processes of embedding patterns are handled in their own time. Others have it easier, and we feel ashamed. I won’t lie–some do have it easier. But most often we don’t know, we weren’t there to see behind the ease, and nobody’s quite vulnerable these days. +

We misunderstand learning, but once, we were in intimate touch with it. Back when we hadn’t yet been subjected to environments of comparison, deadlines, narrow molds, and had our complexities and neuro-diversities amassed into pure functions. I’m not immune to this. At times, learning as an adult feels like a endless chase of the instinctive dance of curiosity it once was. Throw at it: Pomodoro timers, habit trackers and productivity hacks. Yet, it’s only when I sit down to an unmysterious learning practice and truly welcome confusion, chaos, and seeming non-productivity that I feel like I can dance with curiosity again, and learn. +

Fetch a npm package on GitHub without npm install

2024-08-25T16:30:00+00:00

The other day, a npm package was released broken to a private GitHub registry and it wouldn’t install: +
> npm install @company/my-package +This error happened while installing the dependencies of @company/my-package@0.0.34 + +another-package is not in the npm registry, or you have no permission to fetch it. +</code></pre> +The error message is clear: the released package @company/my-package</code> I’m trying to install depends on a package another-package</code> expected to exist in the npm registry somewhere. But another-package</code> is not there. I already knew those packages came from a monorepo, so likely another-package</code> was only an internal dependency in the monorepo, left unreleased. I wanted to inspect the package contents before releasing any fix to be sure, but couldn’t rely on npm install</code> for that. There used to be an option to download npm packages via GitHub UI, but that’s no longer the case. + Finding the package tarball</h2> +One can read the package’s metadata to find a download URL for the package’s latest version. Here’s how: + + +(For private GitHub registries) Grab a classic GitHub token</a> with packages:read</code> permissions (hereafter {GITHUB_TOKEN}</code>). +</li> + +The URL of a npm package published to GitHub is https://npm.pkg.github.com/{PACKAGE_NAME}</code>. Use that to fetch the package metadata, which contains the package tarball URL. +</li> +</ol> + > curl -L -H "Authorization: Bearer {GITHUB_TOKEN}" "https://npm.pkg.github.com/@company%2Fmy-package" | grep -o '"tarball":"[^"]*"' +"tarball":"https://npm.pkg.github.com/download/@company/my-package/0.0.34/3d0304f38791214b09ec92a2262ca1697f" +</code></pre> + +Download the package using the tarball URL.</li> +</ol> +> curl -L -H "Authorization: Bearer {GITHUB_TOKEN}" "https://npm.pkg.github.com/download/@company/my-package/0.0.34/3d0304f38791214b09ec92a2262ca1697f" | tar zx +</code></pre> +That will download the package to your current folder, and you may inspect the package contents now. :-) +
The Bitter Reality of Ebooks and the Kindle Model 2023-08-16T13:55:00+00:00 A few years back, I jumped into the world of ebooks to broaden my reading without stacking so many physical books. I went with the ever-popular Kindle; yet the full weight of “owning” ebooks, particularly from Amazon, was not something I understood. +…Until I decided to break up with Amazon, despite its convenience. You know the drill: Amazon exploits workers</a>, aggressively avoids taxes</a>, dominates markets</a>, and I was just itching to explore alternative bookstores. The hiccup? My Kindle was firmly rooted and entangled in Amazon’s ecosystem. Without Amazon, I could no longer conveniently or legally read books on my Kindle, and without Kindle, I could not legally read books I once purchased on Amazon. + Here’s what I’ve learned while attempting to part ways. + It all begins with “DRM”</h2> +Digital Rights Management (“DRM”) might not be a household term, yet its fingerprints are everywhere. Ever wondered how we consume content via proprietary software, rather than owning the content? + Think Spotify (you never own the music), Netflix (you never own the film), Adobe Creative Cloud (you never own the software), Steam (you never own the game), and Amazon Kindle (you never own the ebook). You download those proprietary software on your device, not the content itself. While you may have a license to the content, but it’s not truly yours. +The use and distribution of the copyrighted content provided by those services (and many others) are restricted by DRM (“Digital Rights Management”) technologies, implemented in various ways, increasingly restrictive and controversial</a>. While DRM aims to address the legitimate need of copyright protection, it fundamentally reshapes the landscape of intellectual consumption, often at the expense of user privacy and freedom. For example: + + +Content Sharing: DRM often limits, or restricts altogether, the ability to share, lend and gift content outside of the same ecosystem. +</li> + +Content Portability: DRM can authorise content to only a specific set of devices or apps, and restrict the supported file formats (even to a proprietary format). That limits content migration across platforms, technologies and devices that better suit you. +</li> +</ul> + The points above reveal an alarming side-effect: dependency on the ecosystem, or "vendor lock-in", which is detrimental to individual freedom and market competition. When content is tightly bound to the platform, disengaging becomes challenging. And when you're limited to sharing only within an ecosystem, your social circle gets roped in too. Kinda seem like cute digital mutualism until it's a toxic relationship you can't leave. + + +Content Perpetuity: DRM cannot guarantee perpetual access to content. If a service or platform discontinues the content or themselves entirely, you may simply lose what you purchased. In fact, that has already happened</a>, more than once</a> or twice</a>. +</li> + +Content Geographical Restrictions: DRM can prevent access to certain content based on location. With the internet alone, we could technically provide equal access to cultural and educational resources – DRM kills that. +</li> + +Content Offline Access: DRM often requires online authentication or periodic online checks. Not very nice in low connectivity areas or during travel. +</li> + +Personal Identification: DRM requires authentication to consume content. By withholding identifiable information, DRM systems may also monitor behavior and consumption patterns and then profile you. You’ve got nothing to hide</a>? Well, perhaps it at least bothers you to have to login? (And if that keeps going on we might soon have login on physical books too?! And there will be no refresh token cookie irl?!?????)</a> +</li> +</ul> + All those “side-effects” (given they are actually unintended 😉) of copyright protection through DRM conveniences corporations. Corporations may not only protect their profit but also actively profit through DRM, charging high customer cost while delivering zero customer value. + Finally, because DRM implementations vary so much, it’s nearly impossible to determine your rights without diving into lengthy terms of use agreements. The restrictions are rather obscured by clever marketing – you’ll soon see. + Leaving Amazon, and failing</h2> +Do you still remember I was trying to break up with Kindle? I get too hung up sometimes but let’s not forget why we’re both here, right!!?! + First things first, let me make it clear – I did not want to give up ebooks. It’d been a pleasure to be able to dive into new literature and keep only the gems in my bedroom bookshelf. And I could also carry a multitude of stories effortlessly during my travels. + Secondly, I had no intention of trashing my Kindle. It was a fully functional piece of hardware, and it worked well. + So here was my grand plan: I’d log out of my Amazon account on the Kindle, and source my ebooks somewhere else. Seems pretty straightforward, right? But the hurdles kicked in right from the very first step. +FuN fACt: Kindle sales are not very profitable to Amazon</a>, as they hope to make up for it with e-book and app sales. + As it turns out, signing out of my Amazon account meant every single piece of content I’d ever acquired through Kindle would vanish into thin air. On Kindle, your books are tied to your Amazon account. + That was an unforeseen repercussion. I naïvely expected to hold rights over books I’d purchased regardless of whether they were digitally or physically distributed. So I was disappointed and surprised – with myself, the state of things; both. And yes, I clearly had not read Kindle terms of use back when I got into the ecosystem (otherwise you wouldn’t be reading this! 😉). + FINALLY reading Kindle Terms of Use</h3> +The latest Kindle Store Terms of Use</a> (Last updated: November 30, 2022), determines a set of restrictions you buy into when you decide to buy Kindle and Kindle content, DRM-protected or not. The “Use of Kindle Content” section states a couple of DRM-ish things: + +ebooks are meant to be consumed only on Kindle, or Kindle apps.</li> +</ol> +Upon your download or access of Kindle Content and payment of any applicable fees (including applicable taxes), the Content Provider grants you a non-exclusive right to view, use, and display such Kindle Content an unlimited number of times (for Subscription Content, only as long as you remain an active member of the underlying membership or subscription program), solely through a Kindle Application or as otherwise permitted as part of the Service, solely on the number of Supported Devices specified in the Kindle Store, and solely for your personal, non-commercial use. [...] + +when you click “Buy Now”1</a>, you are actually buying a license i.e. renting.</li> +</ol> +Kindle Content is licensed, not sold, to you by the Content Provider. [...] + Coming from DRM-based services like Spotify or Netflix, where you subscribe for access to a collection of music or film, the Kindle model might be a surprise. + Within the Kindle ecosystem, you are able to buy individual content, which does evoke a stronger sense of direct ownership. Yet, when you do so, you’re essentially obtaining a license: every ebook is an one-off payment to a mini-subscription. And that was absolutely not straightforward or intuitive to me. + +you may not lend or sell your ebooks.</li> +</ol> +Unless specifically indicated otherwise, you may not sell, rent, lease, distribute, broadcast, sublicense, or otherwise assign any rights to the Kindle Content or any portion of it to any third party [...] + +your books might disappear anytime.</li> +</ol> +We may change, suspend, or discontinue the Service, in whole or in part, including adding or removing Subscription Content from a Service, at any time without notice. +(Funny enough, I checked Wayback Machine</a> and noticed that one was amended around March 2015, after reports of disappearing ebooks years before. 🤷) + …And embracing the sacrifice</h3> +Delving into the Kindle’s terms brought the truth crashing down on me: I never really had a choice to transition away from Amazon while retaining my content. Severing ties with Kindle came at a cost I hadn’t anticipated, and I felt very exploited for it. + Some might argue I actually had the “choice” to enter Kindle’s ecosystem. And sure, it’s true – I did it willingly, no one coerced me into becoming a Kindle user. But, hey, there’s a nuanced reality here you can’t brush aside: we make our individual choices within systems. There’s an entire environment lying behind the notion of individual choice. + Systems can be designed to subtly exert control or exploit personal choice in ways that aren’t always apparent. You can’t look at individual choice alone overseeing the environment in which those decisions are made. In no defensiveness, blaming on individual choice is, I dare to say, exactly how exploitative systems maintain their facade of legitimacy. And I don’t think being exploited or not should be a choice to be made. + Yeah, a bitter pill to swallow, but a new plan has to emerge out of my anger: to log out of my Amazon account, and therefore leave books I’ve purchased behind, and use Kindle only as an e-reader, not a shop. +Leaving Amazon, and failing less</h2> +After logging out of my Amazon account, I’m left with an anonymised Kindle (I hope). At this point I wonder if I even have the right to keep the hardware I’ve purchased, but so far nobody hasn’t taken it away from me. 😉 So, how can I rebuild my e-book library? +Using Kindle with other bookstores</h3> +Before buying ebooks elsewhere, one needs to understand what file formats are supported by Kindle. The file formats supported by Kindle are MOBI, PRC, PDF, and primarily the proprietary AZW, and the files may or may not be DRM-protected depending on the publisher. Only Amazon sells AZW books2</a>. So my options are: + +MOBI. But no bookstores sell them these days.</li> + PDF. But formatting sucks for reading books.</li> +PRC. I don’t know what that is.</li> +</ul> +So I have no options. \😎/ Bookstores sell EPUB</a> books, an open standard well supported by all e-readers in the market but Kindle. Fortunately, you can manually convert EPUB books into one of the Kindle-compatible formats above. Unfortunately, if the book is DRM-protected (very likely!), you would need to strip out DRM before conversion which is downright illegal LMAOOOOOO!!!!! This drives me CRAZY, but let’s move on. + For ebook format conversions, Amazon fortunately offers Kindle Previewer</a>, a publishing software, but it’s just a little too bloated for my goal. So I went with Calibre</a>, a free and open source e-book manager that does it all. It works wonders! + If you keep your Amazon account, importing EPUB into is easier with Send to Kindle</a>. It's a more convenient option but it often messes up with the book formatting. + Ultimately, using non-Amazon ebooks on a Kindle device can involve various technical and legal considerations, especially when dealing with DRM-protected content. DRM-free book shopping is also limited – DRM is an industry standard! So using a Kindle without Amazon is not just very inconvenient, it’s barely legal. 😉 + The most promising plan seems to be tossing Kindle altogether, and choose an open standard e-reader with less hostile DRM platforms, but that’s for another time. + Amazon caters for publishers, not consumers</h2> +It all makes sense when you put it all together. When traditional publishing giants contemplated the world of e-readers and online stores, they had to be a bit careful about it. With physical distribution, they already had a model that offered a clear sense of ownership and control. Then, remember the music industry’s digital transformation, marked by piracy and revenue decline3</a>? Obviously publishers would be wary of a similar fate. + But in comes a compelling offer from Amazon: a tight grip on digital ownership of books, and a shortcut into an already profitable book marketplace. All or nothing. A captivating promise of control and access which publishers, late to digital transformation, did not pass up. And so seamlessly, Amazon paved the way towards market dominance. 👏 + Today, Amazon also positions itself as a platform for emerging writers and attracts independent publishers. So does Spotify for musicians, and Steam for game developers. For both publishers and consumers, content discovery is what’s great about such platforms, despite their license model. + Alternatives like Bandcamp (music) and GOG.com (games) also promote publishers’ content. In contrast, their DRM-free4</a> model ethically caters to both consumers and publishers: the consumer has direct ownership to content, and publishers get their content secured, even earning more5</a>. How does that work? Fingerprinting content files (i.e. watermarks), but above all, cultivating consumer trust and transparency, and a sense of community and support for artists. + Final words</h2> +While writing this, an analogy came to mind. + Picture when you buy a physical book from a store. You know that book will patiently await you right where you left it and not vanish into thin air, whether you frequent the store or it eventually shuts down. That store is unaware of your identity. It doesn’t know when you open or close the book, nor does it know which passages you’ve highlighted. You can even lend the book to a friend, regardless of whether they shop at the same store or if the store recognizes them. And that both of you can go buy books elsewhere later with no strings attached. + But I know that’s kinda corny. It’s an oversimplification. Digital content IS different, and copying files is far easier technically than producing physical copies. We do have new challenges. + Yet, while the analogy might not outright invalidate DRM as a solution, it can serve as a reminder of the current asymmetry of our digital rights today. A nudge to the way our essential rights are exploited within the current framework of digital copyright protection. And, ultimately, it extends an invitation to reimagine it from the ground up. Perhaps looking at how other platforms like Bandcamp have already done so brilliantly, perhaps radically starting at copyright itself. +Keep reading</h2> +…on how despite massive technical effort and corporate interest, DRM is a flawed security model. + +Open Rights Group: Digital Rights Management</a></li> + Defective by Design: Guide to DRM-Free Literature</a></li> + Defective by Design: DRM FAQ</a></li> + Comparison of e-readers: File format support</a></li> + DRM is Toxic to Culture</a></li> +</ul> +^{1 +As of 16/08/2023, Amazon’s checkout button for Kindle ebooks is labeled “Buy Now”. +</div> +}^2 +“Kindle User Guide 4th Edition</a>, p. 39 +</div> + ^3 +Ulrich Dolata, “The Digital Transformation +of the Music Industry: The Second Decade: From Download to Streaming” (2020)</a>, p. 7 +</div> + ^4 +See Are Bandcamp’s download formats DRM-free?</a> and GOG 2022 UPDATE #2: OUR COMMITMENT TO DRM-FREE GAMING</a>. +</div> + ^5 +In comparison to Spotify, whose profit margin for publishers is often questioned. See Ben Sinano: Musicians Say Streaming Doesn’t Pay. Can the Industry Change?</a>. +</div> + Long Time No See 2023-06-30T11:19:00+00:00 In the past three years, a wild mix of stuff dragged me away from writing. More time 🌳 offline ⛰️, which was great. Then a demanding role in a small team, the chaotic grip of a global pandemic, increasing perfectionism, and a blossoming and ultimately collapsing relationship – which all conspired to shake up my pursuits and thrust me into an introspective whirlwind. And as if that wasn’t difficult enough, I lost two years’ worth of drafts in a backup blunder. + Whenever I attempted to restart, I found myself entangled in a web of what still resonated with me and what no longer did. But hey, listing more excuses would only scratch the surface. I recognize now, after seeing how little it takes for me to be back, that parts of me were simply in disarray. Yet, as I come together again, so does my motivation to reclaim what I enjoy, and make time for it despite the busyness and excuses. +So, last night, I did what I do best: I embarked on an in-one-sitting endeavor! I migrated this blog to Zola</a> (a speedy static generator written in Rust), so this WeBpAg3 remains therefore static and snappy af, joining the <512 kB club</a>. Letting my creativity flow with Tailwind</a>, I gave my WeBpAg3 an extravagant-outrageous look, and made sure it’s accessible. I rewrote my introduction like a million times. I sifted through my writings, organising and archiving some, and lo and behold!: I stumbled upon those lost drafts hidden away in the depths of my physical backups. Pretty thrilling. As a friend once told me, good things happen when good things happen. + Long time no see! It all feels quite nice, if you ask me. 😉 + What I've Learned by Simply Journaling 2020-04-20T00:10:15+00:00 In 2018, circumstances inevitably changed and I began taking up much more in life. I was under stress, regardless of being on the safe side, and the patterns that kept me grounded were no longer holding up. +Back then, seeing the big picture was unattainable with the stress snowballing and skewing my perspective. Dwelling in my head, paving the way to learned helplessness</a>, I decided to try out journaling. + More than a year later, I can finally say alles gut. Although circumstances haven’t changed much, I certainly handle them better. I keep journaling as of today, and am excited to share my setup and (hopefully) motivating takeaways! + How I Journal</h2> +I did not go for the traditional diary format. I decided to Bullet Journal, a flexible journal method founded in quick lifelogging by means of a pen, paper, and bullet points. + Pen and paper pull me out of my head and let me continuously evolve my notebook as my needs change, since there is no predefined template. As for bullet points, we all know their efficacy: hasty logging and later reviewing at a glimpse. +Method</h3> +Peek into Bullet Journal official page</a> for an overview, as I won't dive into the framework basics. + The Bullet Journal framework is made out of four fundamental “collections”: Index, Daily Log, Monthly Log, and Future Log, plus custom collections you find valuable. After a while of tinkering around, I came to some insights and tweaks. + + +Index turned out useful when I added custom collections, as those usually end up scattered across the journal and thus hard to find. +</li> + +Daily Logs is where I keep track of notes, events, tasks, thoughts, and ideas. (All mixed together, which portrays a day accurately if you ask me.) I recommend using signifiers and nesting (for a tree-like view) in bullet points to convey meaning with ease, as Bullet Journal suggests. +</li> + +Monthly Log didn’t work for me. I steer towards weekly or quarterly ranges. Also, my online calendar is more practical so I couldn’t bother drawing calendars every month. +</li> + +Future Logs are useful to migrate tasks or events to upcoming months, for when you don’t get something done but can’t “nevermind” it either. +</li> +</ul> + As for custom collections, the Bullet Journal ecosystem is huge! I’ve seen stuff of all kinds out there: finance/sleep/food/water trackers, recipes, trip planning, doodles, and whatnot. Yet, these are the ones I always come back to: + +Diaries: longer diary entries or brain dumps without the limitation of bullet points, for when I feel like it.</li> + Habit Trackers: a simple daily tracker to monitor or develop habits across weeks, e.g. meditation, alcohol intake, call family.</li> + Weekly Logs: my weekly variation of “Monthly Log”, with upcoming events and small goals for the week. Usually done on Sunday or Monday.</li> + Quarterly Logs: my quarterly variation of “Monthly Log”, with upcoming events and big goals for the quarter.</li> +Year Retrospective: a straightforward year review regarding what did and did not go well, what to keep or let go from last year etc. +I journal spontaneously throughout the day, but mostly in mornings or evenings. I do it every day, even when I don’t feel like it. In the long run, that’s gotten me to fathom my anxieties by having them logged as well as what was up days before. It goes a long way to flip through logs of piled up chores, social isolation, binge drinking, and sleep deprivation, to later find yourself taking down “I am anxious. Can’t do shit”.</li> +</ul> +Be that as it may, I don’t keep it all gloomy. With my throughput in mind, I may also soften up my daily logs with receipts from exquisite restaurants I come across, cute post-its from friends, or even silly useless quotes from fortune cookies. + At last, I have to say I’m not really a big planner so you can see that’s not what I optimise my journal for. All I strive for is a little awareness of whatever I’m doing for the time being. I enjoy a spontaneous and organic life, and that’s gotten me far enough to make me happy. +Pen & Paper</h3> +</picture> + +My 2019 journal (left) and 2020 journal (right).</figcaption></figure> +In 2019, I used an A5+ (slightly wider than regular A5) dot-grid notebook. It’s bulky to carry around but I don’t regret it: the pages are wide enough to encourage writing. The quality of its pleasing yellow paper is outstanding, thick enough to prevent ink from leaking through. I ended 2019 with a few pages empty. + This year, I went for something more portable: an A6 dot-grid notebook. It took me a while to get used to the size constraints, and I’ve been certainly more straightforward with my logs. I am pretty sure I will have no pages left this time. (Wondering what was the advantage of it all as I’m not going anywhere anyway thanks to COVID-19.) + As for pens, I use different colours of a 0.4 mm fineliner. +What I’ve Learned</h2> +I'd not assume these stem necessarily from the way I set myself up. Audio or video recordings, traditional diary, and other journal formats are worth exploring and might help just as well. + + +Less overwhelm, more time. To truly chill out when life gets overwhelming, you gotta plan ahead. Especially in already busy weeks, I use my journal to put down chores I commit to get done, prioritising what I signify as deadline-sensitive. Before, with my tendency to overfocus, I’d take up activities without planning and end up neglecting my responsibilities and needs. Imagine how far this can go! +</li> + +Emotional awareness. I’ve gained a grasp of the phenomenology of my emotions and the lens through which I see life, markedly my cognitive distortions on stressful days. Attitudes like pessimism inevitably surface as you jot down negative thoughts all the time. Being mindful allowed me to reframe negative views, and turn obstacles into opportunities. +</li> + +Better retainment. It’s easy to fall into the trap of “I have a bad memory” when one has been busy and mooning for so long. Leading a busy life mindlessly is not what I strive for, and journaling only feeds into that: I hold dear people, moments, promises, and no longer miss so many appointments (planning helped here too!). +</li> + +Constant assessment. Journaling is a tool to assess the present as well as the past and the future. By peeping into where I’ve been, what did/didn’t go well, or who I have been with, for instance, I can ponder more sensibly on my growth and relationships. Early feedback on my own life, sort of, to leverage self-improvement in relationships, health, work, and so on. +</li> +</ul> + Pitfalls</h3> + + +Perfectionism. Obsession over constant logging or perfection is right at the door for you to slip into. On social media (Pinterest, YouTube), everyone’s journal seems visually-appealing every day without fail. Even Bullet Journal, a method dead straightforward, can be a rabbit hole. Remind yourself to solve your problem in a way that enhances your daily life, not burdens it. You gain absolutely nothing from buying into slices of life people sell online. +</li> + +Habit-building. When not a habit, journaling is just another chore. Make it effortless and engaging: establish a routine (if that’s your thing), designate it a place where it’s always within reach, or tailor the framework to your needs. If you enjoy drawing once in a while, why not? If you have no patience for 29872 different pen colours, why do it? If you want to write about your day with your partner in bullet points instead of coming up with a best-seller love story, who cares? +</li> + +Procrastination. Journaling constantly nudges you to look back at your life and how you’ve been spending your time and energy. That can be challenging and won’t change. For starters, you might come to the unpleasant realisation that you self-sabotage, or that a certain relationship is fading away. If you are avoidant, you will most likely put off journaling often; not because of the method or routine, but fear of what you may find – fertile soil for procrastination. +</li> + +For pen & paper… No backup. Some companies have tried, but what’s hand-written won’t sync with a cloud server. You do carry the weight if traveling or taking it to work, and it’s probably gone if you spill coffee on it. I, though, think the trade-off is worth it and haven’t looked back. +</li> +</ul> + Final Takeaway 🥡</h2> +I am all for simplicity, yet that didn’t keep my mind from boggling when I realised such a simple tool turned out to be a game-changer. Starting off was not easy, but the benefits showed up and kept me motivated – a rewarding feeling I wouldn’t expect so hastily while building a new habit. Today, it’s just effortless and natural. + Ultimately, I hope this stimulates you to try journaling in whatever way and to deem simple tools as helpful to uncomplicate and improve our lives. + References</h2> + +Learn Bullet Journal</a></li> +</ul> + How to Spy on a React Prop with Jest 2019-10-31T14:15:42+00:00 When we want to test whether a prop has been called, mocking the prop in the component is usually the preferred way. This is how it goes with Jest</a> and Enzyme</a>: + const buy = jest.fn(); +const wrapper = enzyme.shallow(<button onClick={buy}>Buy</button>); + +wrapper.simulate("click"); + +expect(buy).toBeCalled(); +</code></pre> +You may also want to spy on the prop directly, when the component is tested along with a provider passing down its props. + const wrapper = enzyme.shallow( + <ClickProvider> + <button>Buy</button> + </ClickProvider> +); +const buy = jest.spyOn(wrapper.instance().props, "onClick"); + +wrapper.simulate("click"); + +expect(buy).toBeCalled(); +</code></pre> +I am using Enzyme however you should be able to spy on similarly using other testing libraries – just make sure you are spying on a function in the props coming from the component prototype (as in wrapper.instance()</code>). + That’s all. Just posting it here cuz I couldn’t find it easily anywhere else. + Setup for Audio Interface with Guitar Rig 5 on macOS Mojave 2019-08-18T22:19:05+00:00 Setting up Guitar Rig 5</a> on macOS Mojave seems not to be straightforward. + Although I had gotten the signals to be sent from my guitar to the audio interface and from the interface to Guitar Rig, somehow it’d still not work. Instead of using my audio interface as the input and output device on Guitar Rig, I had to set up an “aggregate device”. + This how you can do it too. + (My specs, just so you know:) + macOS Mojave Version 10.10.14 +Guitar Rig Pro 5.2.2 +Audio Interface Steinberg UR22mkII +</code></pre> +Audio MIDI setup</h2> + + +Open “Audio MIDI setup” in your Mac. (It’s a tiny secret sound manager shipped along with the system, you’ll find it.) +</li> + +At the very bottom of the app, there is a small + (“plus”) button wherein you should select “Create an aggregate device”. +</li> + +Set up your “aggregate device” with your 1) audio inteface and 2) speakers/headphones/whatever – which should be all shown up there, given the setup is correct. Remember to give your device a remarkable name – I suggest FUCK COMPUTERS AND AUDIO. +</li> +</ol> +</picture> +My custom device in Audio MIDI Setup on macOS.</figcaption></figure> + +Go back to Guitar Rig. In the context menu “File”, go to “Audio and MIDI Settings”. In the “Audio” tab, select your aggregate device as the device, instead of only the audio interface as you were doing before; then configure input/output as expected in the “Routing” tab.</li> +</ol> +Should work! If it doesn’t, this guide by Native Instruments on how to troubleshoot audio</a> and others guides on the website might help. Depending on your audio interface, make sure the right driver setup is in place – you can try out ASIO4ALL</a>. + + If it still doesn’t work, I am sorry and prolly have no idea. Have fun. + OMG Climate: Reflecting Together on the Climate Catastrophe 2019-05-30T11:39:14+00:00 </picture> +Credits: NASA’s Scientific Visualization Studio/Kathryn Mersmann.</figcaption></figure> +Planet Earth, May 2019. The UK has announced a state of emergency for climate change</a> and Canada considers the same</a>; we are more confident about our model to capture rising global temperatures</a>, and students all around the world walk out of school protesting the lack of climate action</a>. Yet, not enough of us are genuinely concerned about the role we’ve played on this catastrophe. + A Saturday afternoon of May and a few square meters in Berlin were what a couple of people needed to open– and voluntarily discuss how we impact the Planet to change and how those changes impact us. Topics ranged from radical solarpunk utopia to more down-to-earth and short-term ideas within our generation’s reach today: musings about climate change awareness, sustainability policies for companies, traveling sustainably, tech tools for political change, and how to get out of our bubbles and active listen to other realities. + In this post, I’ll be sharing my personal notes on that engaging and constructive afternoon. There will be, also, references at the end of this post so you can keep yourself posted. + Pitching and picking topics for discussion</h2> +OMG Climate is an unconference, meaning that attendees proactively come up with the agenda and topics to be discussed. To kick it off, we got instructed to pitch topics for discussion that’d be prioritised also by ourselves into tracks, attended based off our preferences. Everyone was expected to have at least a certain knowledge, even if rather tacit, about the challenges we’re facing right now with the climate emergency. + These were the tracks of the first OMG Climate: + +Track 1: “Low-carbon travel” / “Green Mafia” / “How do you sleep at night? Coping with climate anxiety”</li> + Track 2: “Tech tools for political action” / “Circular economies: Re-use and tech” / “Company sustainability policy template”</li> +Track 3: “Solarpunk, imagination and excitement” / “CO2 Offsets as an API and tracking carbon” / “Climate change awareness in developing countries”</li> +</ul> +We had enough attendees for tracks to make for productive discussions. Listening and talking to one another, while facilitated by a volunteer, did the job on keeping up an constructive flow between finding root causes and ways to take action. +</picture> +During the "Green Mafia" discussion.</figcaption></figure> +I’ve joined “Low-carbon travel”, “Green mafia”, and “Climate change awareness in developing countries”, so these are the ones I have more insights about. Towards the end, we all got together to wrap it up, and I have to say: all tracks were interesting, so don’t restrain yourself to this post! + The following notes don't reflect directly what's happened or everything that's been said in the event, it's rather my personal perspective. They are also somewhat vague, but I hope you can benefit from them somehow. +Low-carbon travel</h2> +Air travel, even when occasional, has an environmental impact</a> difficult to make up for no matter how many bamboo toothbrushes we gift our friends, how often we commute by bike or how vegan is our diet. + With low airplane ticket prices getting more popular than ever and enabling people to travel more, how can we make traveling sustainable when not traveling to begin with is not an option? That was the question we kicked off the “low-carbon travel” discussion with. + Meeting notes</h3> +</picture> +Collective sketch notes about the low-carbon travel track</figcaption></figure> + +In our circle, everyone seemed to have access to the privilege that is air flying.</li> + We began exploring traveling by breaking it down into traveling for work vs. pleasure.</li> + Ground travel might be an option; however, it’s rather time-consuming and hence less appealing in a capitalist society where time translates to money. How can we shift the paradigm?</li> + Instead of seeing longer trips as wasted time, we should begin seeing the journey as part of the trip.</li> + Traveling less: We often optimise our trips to visit as many places as possible; instead, we can optimise for depth and start going to fewer places for a longer time. Think: going to a European country and making the most of it, instead of going to 999 different countries just because they are 1-hour-flight away from each other.</li> +Share practical solutions for people to make trade-offs, EcoCost</a> rather than overwhelming scientific evidence.</li> + What if companies supported employees whose carbon footprint is the least?</li> + Green travel agencies and flying policies.</li> + Search engines for flights obviously don’t suggest alternative ways to get to a place when a plane is definitely not the best option.</li> + BVG</a> app, on the other hand, recommends walking instead of taking public transport sometimes.</li> + Transport apps could also order route options by the least environmental impact.</li> + The car industry should be ashamed of its climate record.</li> + The train industry is not modernised and integrated, rather rigid.</li> + Investment on 10 km of autobahn could pay off the renovation for bike lanes all over Berlin.</li> + Globalisation vs. environmental footprint: IT workers immigrating usually go back to their countries often since they have the need and resources. I asked whether there was data available on how that situation in particular could’ve increased our carbon emissions coming from aviation.</li> + Business trips by train are possible only among those who have the privilege of a flexible work schedule, such as freelancers.</li> + Making the most out of idle time: we tend to be more creative in idle times, while in a train; not hunching over a keyboard or in an office environment.</li> + “Fast-moving home/office” as an alternative to turn the journey time into productive time.</li> + Frequent flyer levy: A fairer tax system according to how often people fly. Those that fly more should pay more. (More information: A Free Ride</a>)</li> + Airline campaigns often promote the image that everyone should become part of a group of young, urban frequent flyers, visiting another city every few weeks for very low costs.</li> +</ul> +Action points</h3> + +everyone to shift mindsets in regard to traveling.</li> + everyone to vote instead of buying a bamboo toothbrush.</li> + everyone to use and promote tools with different options of transport within a route, instead of blindly going to specific train or flight websites.</li> + everyone to keep consuming local goods.</li> + airline companies to stop promoting flying as a status symbol.</li> +travel agencies to work out more sustainable ways to travel and consider it in their branding.</li> +</ul> +Green Mafia</h2> +How corporate interests and ideologues work to undermine science and make countries doubt about the risks of climate change? Think what stopped Australia, 25 years ago, to act on climate change</a>. + We should fight back! We mused about beating off lobby groups representing the coal, car, oil, electricity, and aluminium industries using their same sneaky techniques, as a Green Mafia. An intriguing and fun topic! + The brainstorming served as a tool to get a grasp on the way those mafias function, and discuss whether the ethical approach is always the way to go when facing a crisis. + Meeting notes</h3> +</picture> +Collective sketch notes about the Green Mafia track</figcaption></figure> + +Leverage civil disobedience and tools of intimidation to influence green policies for the climate, fight extreme wealth and weaken existing mafias such as the oil industry.</li> + How far should one go with non-ethical practices, such as blackmailing or public shaming of those who harm the planet?</li> + What’s ethics after all?</li> + Could we use illegal money to fund our causes?</li> + Could we use legal money to fund our cases? There are ways to get money from the state in licit ways such as from green parties.</li> + What if we made the green cause as profitable for the mafia as oil?</li> + Sell a belief system, or use an existing one such as “harmony with nature”.</li> +Cyber hacking/hijacking internet algorithms to spread awareness instead of climate change denial and fake news as it happens today.</li> +</ul> +Awareness in developing countries</h2> +The rich, the poor and the Earth. +World’s richest 10% produce half of the global carbon emissions, while the poorest half contribute a mere 10%</a>; but climate change affects the poorest people the most. Moreover, developing countries are the most responsible for climate change now, and vulnerable too.1</a> + Coming from a developing country, I was looking forward to this topic! Apart from Brazil, we had people from India too. There was a range of issues that could be tackled within this track, such as the risk of massive displacements of people in developing countries, the need of support to adapt, environment destruction for the sake of economic prosperity, how to approach climate change education etc. + Meeting notes</h3> + +We are building awareness, not “teaching” others about climate change.</li> + Climate change is an existential threat to life, but it seems rather remote if you think about poverty, disease and economic stagnation. How do we educate children for the long-term if, for some of them, not showing up at school tomorrow means not eating at all?</li> + How do we let them know about the risk of massive displacements of people who have no resources whatsoever to move?</li> + Just by existing in a developed country in Europe, our carbon footprint is more impactful than any developing country.</li> + Indigenous people are already defenders and protectors of the environment more than we will ever be in our generation.</li> +Economic development is a priority in developing countries, and politicians may ignore environmental impact for the sake of it. (See Brazil’s natural resources open for business, says Bolsonaro</a>)</li> + Developing countries idealisation of economic development, influenced by “developed world standards”: tall buildings and industries all over the place, where often we don’t see the green implications of “success”.</li> + What about a model of development thats puts together the simple living of developing countries with the green development of developed ones?</li> + How waste affects developing countries; example of Philippines to sail garbage back to Canada</a>.</li> + We could shift the discussion to think about environmental impact in terms of social classes instead of countries. After all, rich lifestyles and “status” in general damage the environment in untold ways.</li> + The Swadeshi movement</a> brought back self-manufactured clothing in India to boycott foreign goods, a part of a movement to liberate India from British control and industrialisation.</li> + When teaching, consider what’s in people’s context, reach and language instead of what’s “out there”.</li> + We should actively listen more to those communities and what’s happening in those countries. Sometimes, instead of thinking that there is something to be taught, we should rather learn from their realities so we can bring about a meaningful conversation.</li> + This is a problem not to be approached by technology, remotely. It’s rather about Politics and Education.</li> +</ul> +Action points</h3> + +everyone to assure inclusivity, cooperation and engagement across boundaries, first and foremost.</li> +countries to keep cooperating efforts internationally through policies, institutional frameworks for development and investments in infrastructure.</li> +</ul> +Conclusion</h2> +Well-led communities that strive for welcoming environments enable the best out of people. OMG Climate has shown that – its unconference format</a> got everyone to take responsibility and engage towards constructive and meaningful discussions about climate change. + </picture> +Final presentations wrapping up the tracks.</figcaption></figure> +Although most of us had a tech background, everyone seemed aware: tech alone will not solve all problems, but we are eager to address them either way. +Learn about Climate Change</h2> + +Reddit: /r/climatechange</a> and /r/globalwarming</a></li> + The Guardian on Climate Change</a></li> + Global inequalities in CO₂ emissions</a></li> + We’re (still) not being alarmist enough about climate change</a></li> +</ul> +More on OMG Climate</h2> + +OMG Climate Event page</a></li> + OMG Climate Medium website</a></li> + #OMGCLIMATE on Twitter</a></li> + ClimateAction.tech</a></li> +</ul> +^1 +Climate Change and Development in Three Charts</a> +</div> + I've Sensory-Deprived Myself In a Tank 2018-12-02T08:01:00+00:00 I struggle every day trying not to be one step ahead. Living everywhere else but the present and leaping through time have become part of how my brain is wired, so I often find myself not experiencing much anymore. +A while ago, a friend told me about his sensory-deprivation experience in some kind of pool, the so-called Isolation Tank</a>. No sight, no hearing, no touch, no taste, no smell – the idea of getting absolutely no input from anywhere struck me as a way to get my perception back on track. I decided to try it out. + On a sunny Saturday of November, I, along with my endless stream of thoughts, floated for 1 hour straight in a soundproof egg-shaped tub shallowly filled up with salt water. This is my report. + Getting In</h2> +With my bathing suit on and no expectations of anything, I showered, got into the tub and sealed down its cover. My body floated easily on that water that thermically felt like my own skin, and a relaxing sound was playing in the background up to the moment my surroundings got all pitch-black. + The first 15 minutes were all about withstanding how restlessly my mind wanted to get out of there. I’ve had done meditation before, but 1 hour was something else. I recalled I worked 8 hours a day, 5 days a week, and therefore I should be making the most out of my Saturday instead. Leisure time! In modern life, that usually means stimulation by means of binge-drinking with friends, uplifting music, delicious food, watching heart-breaking movies…. Quite the opposite of soul-crushingly doing nothing. + The mind just plays a lot of games on you all the time. It tricked me into being physically irritated by the water, its salt, that bogus zero-gravity environment, and that I’d be better off giving up for my own survival – at least, that was how my body anxiously (over-)reacted to it. But there was actually no physiological danger or whatsoever; truth be told, I was way safer than I had ever been throughout that week. I quit panicking. + I came upon different phases of denial, approval and mind-numbness from that onwards. Saw myself bringing up problems and drifting them away. Tried to work out situations I had no control over. Missed music, so made my own by tapping on the water. Went hyper-focused on how I had performed socially last week to what was going to happen in the next few weeks when I eventually hand over my old apartment’s keys to that spiteful Hausmeister who hates my German. + My thoughts just went on super randomly. After a while, I could draw the exact line where each one ended, and got mindful about my weary physical overreactions to them. + Towards the end, I sank into something else: weightlessness, timelessness, solitude were emerging from that isolation. Things started losing shape. Didn’t perceive water. I was either a floating head or a floating body. I had to touch my thighs, boobs, neck just to relieve myself from the uncertainty that being so relaxed made me feel about where I was. + I wanted to come back down to Earth from wherever I was, and, surprisingly, to be myself – the way I was. Then time was up. +Getting Out</h2> +I showered again to wash the salt off. The spa provided a relaxation lounge that was essential to ease the transition, since I had neither desire nor need (important!) to rush anywhere. Hung out there for 1 hour. + The readjusting was an interesting and unexpected phase to me. Had an apple and felt how crispy in sound and taste it was. Drank a glass of water and sensed it going right down through. Read a book and couldn’t make sense of why we humans have ever brought up speed reading techniques in the first place. +Stepping out of the spa, I got savagely welcomed by a gloomy afternoon1</a> undergoing that life I was used to every day. A lot was happening out there: lights of apartments being turned on and out, cars groaning, people running around, traffic noise, the cozy energy of having my friend by my side, sharper textures of the sidewalks’ cobblestones, and the joy of a having a sky whose amount of stars doesn’t depend on the many times we screw up as human beings, thankfully. + Berlin-Schöneberg is quite chill so that’s helped to readjust. I was sensible and my thoughts were vivid and receptive – pretty much the actual poetic mood I strive for, where I settle and listen to what’s being said in order to write it down. A mood that is “highly disturbed by Philosophy”, as Goethe brilliantly summed up to Schiller once: + “I am still hoping for poetic hours, and philosophy, in my case, disturbs the poetic mood, probably because it drives me into the object, for I am never able to keep myself in a purely speculative mood, but have immediately to try and form a distinct conception, and on this account at once fly out into nature. […]2</a> + I had finally my mind drifted towards just as much of the world as it was going on. + Lessons Learned</h2> +My poetic mood didn’t last much – it wore off the day after. + I’ve realized how much we are externally stimulated and easily adapt to it as if it were natural. On top of that, we are internally stimulated by our worries and whatnot: have I paid my taxes? Am I persuading a career? Does my family still love even though I am thousands of kilometers from them? Have I been eating healthy enough? + It turns out it’s clear why we don’t feel much anymore. Our brain gets wired to parallelising stimuli, and we have less and less coming from our body to the head than the other way around. Apart from that, our experience of the world is barely passive: we actively generate it with our biases, mental models, what and how much we consume. Mind shortcuts are crucial, but might restrain us from genuinely experiencing life, getting us to either ignore ou hyper-focus unconsciously. +I, now, have a better grasp of what Erling Kagge meant in Silence: In the Age of Noise</a>, written after he had spent fifty days walking solo in Antarctica: “Everything seemed completely flat and white. […] Eventually, in complete isolation, I began to notice that nothing was completely flat after all. The ice and snow formed small and large abstract shapes. The uniform whiteness was transformed into countless shades of white. […]” + Meditation is the absolute protagonist here, but floating got me into a different flow, and faster. The topic of sensory deprivation</a> is definitely worth-exploring. Think like: If you ditch sugar for a while, it tastes sweeter afterwards. ;-) + This is pretty much what floating offers: sensory starvation and you on your own. You may waste your time and never get to anything, or make even most out of that 1 hour than me. + Personally, I can’t wait to do nothing again. + +^{1 +Just another Autumn day in Berlin. +</div> +}^2 +Goethe (and Friedrich Schiller). Correspondence Between Schiller and Goethe from 1794 to 1805</a>. Translated by George H. Calvert. +</div> + How I Lock My Bike in Berlin 2018-08-30T07:00:00+00:00 1 year with a bike in Berlin, and counting... + I bought a bike 2 months after moving to Berlin, and a really good lock 1 day after. +With no clue about the theft scene in Europe – Berlin, in special –, I did myself some research on /r/berlin</a>, /r/bycicling</a> and a few other places around the internet. What I did find out? Well, the numbers on bike theft are quite concerning</a>. + Nevertheless, after witnessing some people getting their bikes stolen, I feel privileged to say that it’s been more than 1 year I’ve got my bike. If that is because of my good lock or my good luck, I’ll never know. + But I can tell you about the lock. + My lock setup</h2> +I generally agree that you should invest as much as you can afford in your lock setup. I’ve put a considerable amount of money on mine because I deeply care – in other words, I have no psychological resilience when it comes to bicycles so losing mine would definitely get me in tears. + If you care about numbers without any trustable source, I've seen recommended somewhere that you should be investing between 10%-20% of the bike price in a lock. 🤷 +Therefore, considering the price of having to go home by feet and with tears in my eyes, I did the best I could and went for the Kryptonite Evolution Mini-7 with Double Loop Cable</a> (highly recommend you to check their website for more information). + I make sure my bike’s frame and both wheels are locked to a fixed rack – cemented into the ground, ideally. + </picture> +My tiny yellow bike parked and properly locked at the office's parking space! Locking up the U-lock to the front wheel instead is a good alternative. Also, I often wrap the steel cable through the rack.</figcaption></figure> +I had considered the Kryptnonite's New York Fahgettaboutdit</a>, but I found it way too heavy and the safety factor difference didn't pay off for me at that time. I'd recommend it if an extra weight is no problem for you though. + For I still have my bike after 1 year, I am honestly happy with my choice. The lock came with: + +Three keys with an unique number. For your information, Kryptonite has a system where every key gets a number</a>, so you can order replacements online in case you mess up.</li> + A handy mount made by Kryptonite: Transit FlexFrame U-Bracket</a> (not visible in the photo because it’s in the top tube), so I don’t have to carry the U-lock in my backpack or whatever.</li> + Manuals that I didn’t read and got recycled.</li> + 1 year coverage according to the Kryptonte’s Anti-theft Program</a>, because the security rating is high enough.</li> +</ul> +I’ve read a couple complaints about the lock not fitting both the wheel and frame to most city racks, however I’ve managed to do it in most racks around Berlin. It’s definitely not the most flexible and spacious lock, but thieves would love some extra space to do their work too, so I think it’s just the size it should be after all. +In the worst-case scenario, there is always the Sheldon Method lock strategy</a> – or its modified version</a> – anyway! + What bike locks are about</h2> +When looking for a lock, instead of (only) asking yourself what’s the best lock ever, ask “How much trouble am I putting a thief into with my lock strategy?”. + It hasn’t been enough stressed that locks do NOT prevent determined thieves with their lock pics, cable cutters, bolt cutters and angle grinders to steal you bike. Period. + Locks do, though, make it harder for thieves to pick your bike, by increasing the “risk” factor in the risk/reward calculation done before they attempt to steal. + It’s all about making it harder. And how do you do that? By having a diverse lock setup, and, just as important: by being extremely careful on where and how to park. + Don’t think just U-lock: saddle locks, wheel locks might be worth-checking too! One awesome lock is just one at the end of the day, and the more tools the thief needs to carry out, the better. +Looking further</h2> +Some articles I’ve read last year and that might be interesting if you own a bike and want to learn more on how to keep it safe. + +Best Bike Lock</a>: Review of several bike locks and learnings on how to pick a good one.</li> + How to Lock your Bike</a>: Great tips on where to park your bike and what to lock it to.</li> +</ul> +There are a lot of cool videos out on YouTube too, e.g. “How to Lock your Bike” from GCN</a>. + Have a nice ride! 🚲 + Working Better with Git for a Clear History 2018-08-04T07:00:00+00:00 Your teammate worked on a few improvements in all forms of the company’s website. At some point you, also a programmer, are asked for a code review. + This is the feature branch’s commit history you get in the Pull Request: +[290xx26] Resolve merge conflicts +[9efxxf2] Refactor event listener for form fields +[5d9xx5a] Update snapshots +[948xxfa] Update dispatch event +[f5xxea1] WIP +[f8xxaae] Revert change +[49xxf55e] Revert changes +[02xxdf1] Update snapshots +[21xx329] Pass down prop +[28xxa865] Fix onChange event and add minimal design in form +[cfxx37c] U[date snapshots +[cfxx36c] Update form to handle onChange event for autofill +[242xx25] Fix another bug with onChange +[f7xx738] Update form component +[09xx868] Update snapshots +</code></pre> +It seems like a lot, when actually those improvements are simply 1) fixing a bug with event handling and 2) introducing a minimal style to them. It just that it takes time to visualise that. +Indeed, committing often to a branch is a good practice1</a> and commits are supposed to be low-level rather than huge. However, a commit is applicable when you have a meaningful, self-contained batch of work to log to the history – and updating Jest snapshots is not it. + How about the following history? + [9efxxf2] Refactor event listener for form fields +[cfxx37c] Add minimal design in form +[cfxx36c] Update form to handle onChange event for autofill +</code></pre> +That history communicates in a clear way what in the codebase has been changed in order to get the improvements done. If you want to know how it’s changed, it’s just a matter of checking out a particular commit. +Why a clear history matters</h2> +Apart from facilitating code reviews, since reviewers could grasp the context of the changes right at the first glimpse, a clear Git history is healthy for the project. + When commits started to reflect one’s workflow rather than the work done itself, the history turns into a mess of both meaningful and meaningless logs, hard to navigate through and undo changes (since commits are “checkpoints” of work). It’s highly likely that, as time goes by, developers will stop caring about the source code history as the powerful resource it is. + *The final Git history should reflect your work not the way you worked. + You begin to lose the benefit of source code management with a messy history, which was supposed to reflect how the codebase evolved over time. +A better relationship with Git</h2> +There are very common comprehensible reasons – yet not excuses at all! – for developers to unnecessarily commit. I can think of: + +“I had to update snapshots/fix unit test/code formatting/a typo in something I introduced.”</li> + “I had to merge master.”</li> + “I wanted to save my work.”</li> +“I don’t necessarily follow a clear flow – I am productive when I work in iterative way and usually do a lot of things at once.”</li> +</ol> +They can all be worked out by developing a better relationship with Git itself. That might take a while at first, but when it’s part of your daily workflow, you barely think about it at all. (I promise!) +First, let’s talk Git rebasing</h3> +Git rebase</a> is a very powerful tool to reorganise your commits. It does a lot, so I won’t get deep into it. + The command git rebase</code> has an important tool you should get comfortable with: interactive rebase. Let’s say we want to reorganise the latest 3 commits: + git rebase --interactive HEAD~3 +</code></pre> +HEAD</code> points to the current branch in your Git repository. You can use @ as an alias as well: @~3</code>, or the commit hash. + Interactive rebase will provide you a text interface with the list of the commits (in this case, within the range HEAD~3..HEAD</code>) that are about to be rebased and actions you can apply to them: +pick [242xx25] Fix another bug with onChange +pick [f7xx738] Update form component +pick [09xx868] Update snapshots + +# Rebase 242xx25..09xx868 onto 242xx25 +# +# Commands: +# p, pick = use commit +# r, reword = use commit, but edit the commit message +# e, edit = use commit, but stop for amending +# s, squash = use commit, but meld into previous commit +# f, fixup = like "squash", but discard this commit's log message +# x, exec = run command (the rest of the line) using shell +# +# These lines can be re-ordered; they are executed from top to bottom. +# +# If you remove a line here THAT COMMIT WILL BE LOST. +# +# However, if you remove everything, the rebase will be aborted. +# +# Note that empty commits are commented out +</code></pre> +pick</code> just means that commit is included. It's the default. + Editing that file (either by applying actions to commits or reordering them) and closing it will reapply those commits to the branch. We’ll explore some scenarios where that is useful. +Rebase instead of merge</h3> +The branch that you branched from has been updated (let’s call it master</code>), so you need to fetch latest changes and merge that into yours with git pull</code>. Instead of merging and introducing an ugly new commit for that, you can rebase and pretend that nothing ever happened in the first place. +git pull origin master --rebase +</code></pre> +"Why isn't that the default then?", you might ask. I'd guess they didn't want to make a feature that rewrites history part of the default behaviour. +Squash commits when you can</h3> +You need to fix a typo, update a test, or include anything else that should have actually been part of a commit previously introduced. You can create a new commit and later squash it to the initial one with rebase. +git commit -m "Update contact form tests" +git rebase -i HEAD~2 # act on top of latest 2 commits +</code></pre> +Interactive rebase will show up, and you can mark that “Update contact form tests” as the commit to be squashed into a previous one by changing pick to s</code> (squash). + The squashed commit has to come exactly before the commit you want to squash into, so you might have to some reordering. +Fix up and save time</h4> +Using the --fixup</code> flag along with the commit hash of the previous commit will mark a commit as a fix of an existing one. Then, when you rebase with --autosquash</code>, they will… well, automatically get squashed. + Let’s say we have fixed a typo in the commit i2r923</code>: +git commit --fixup i2r923 +git rebase --autosquash 9ef00f2 # one commit before above +</code></pre> +You can configure Git to use the --autosquash</code> flag by default when rebasing. I do that so you can check my dotfiles</a> if you're curious. + Quite often, you’ll know how far you’re traveling from the current commit (HEAD). Instead of specifying hashes, you can just use HEAD</code> as a reference to previous commits: + git commit --fixup HEAD # fix 1 commit before HEAD +git rebase --autosquash -i HEAD~1 # squash latest 2 commits +</code></pre> +Stash to save your work in progress</h3> +You want to check or change other branch’s files, but don’t want to commit unfinished work either. You can stash your work in progress (“WIP”): +git stash +</code></pre> +That stores everything from your working directory into stash. It’s so useful in my day-to-day work that I honestly often cry using it. +On how to get your work back, name your WIPs, or stash specific files, refer to the docs on Git staging</a>. No way I am better at explaining than the documentation itself! + Commit selected chunks of your work</h3> +Remember the “I work in a very messy way, iterating between features” excuse? This helps. (It helped me yesterday when I refactored and introduced something new to it – should not be done altogether! – at the same time without noticing.) + Besides only adding a specific file to your commit with git add</code>, you may want to add only a chunk of the file’s code to a commit. That can be achieved with the --patch</code> flag: +git add --patch +</code></pre> +That’s another interface you’ll have to get comfortable with. You can also try out its --interactive</code> option. +Using VS Code?</h4> +VS Code has a powerful built-in Git editor that allows you to add chunks of code to a commit. To stage specific lines to commit later, open VS Code’s Git editor, select the lines of code you feel should go into a commit, and “Stage selected changes” by right-clicking on it. +</picture> +Changed the whole thing but want to commit only a chunk of it? VS Code has got you covered.</figcaption></figure> +The Command Palette</a> also has a “Git: Stage selected changes” option. + Rename commit messages for meaning</h3> +You had a look at the final history and found out your commit messages need some love. To change your latest commit (HEAD), you can just do git commit --amend</code>; for other commits, you’ll have to rebase. + Let’s say you want to fix the latest 5 commits: +git rebase -i @~5 +</code></pre> +That will open up the interactive rebase you’re already familiar with. Find the commit you want, change pick to e</code> (edit), and save and close the file; after Git rewinds to that commit, edit its message with git commit --amend</code>, and run git rebase --continue</code> when you’re done. +Got a clear history? Push it!</h2> + +Commit Often, Perfect Later, Publish Once.1</a> +</blockquote> + Make sure that your branch has got a clear, readable and meaningful history… + git log --oneline +</code></pre> +Then push it into the remote repository! +git push origin head +</code></pre> + If you have already pushed (Y THO???!), you can (carefully) use the force option (-f</code>) to rewrite the remote history. +Extra: Fixing the first history</h2> +Remember the first history? We can fix it. It’s definitely harder to change it after it’s done, but totally doable with rebase -i</code>. A possible solution would be: +squash [290xx26] Resolve merge conflicts +pick [9efxxf2] Refactor event listener for form fields +squash [5d9xx5a] Update snapshots +squash [948xxfa] Update dispatch event +delete [f5xxea1] WIP +delete [f8xxaae] Revert change +delete [49xxf55e] Revert changes +squash [02xxdf1] Update snapshots +squash [21xx329] Pass down prop +pick [28xxa865] Fix onChange event and add minimal design in form +squash [cfxx37c] U[date snapshots +pick [cfxx36c] Update form to handle onChange event for autofill +fixup [242xx25] Fix another bug with onChange +squash [f7xx738] Update form component +squash [09xx868] Update snapshots +</code></pre> +Be mindful about your decisions and make sure you are not losing work along the way. I deleted commits unused commits (WIP then reverted), squashed “fix” and “update tests” commits, and then picked only those that are meaningful batches of work. + I could have also split Fix onChange event and add minimal design in form</code> into two separate commits… But that’s for a future post. +Final considerations</h2> +Nowadays, I can say for sure that Git helps me to work better. Those techniques you’ve learned are all part of my daily workflow. + There is always something I don’t know about Git though, so I keep exploring. I recommend you do to do the same, and you can start right from your command line: +git help -w reset +</code></pre> +Finally, if somehow you don’t feel comfortable with moving around your work from the command line, I’d recommend Git GUI clients2</a> – they are powerful and simplify visualising branches and its commits, especially when it gets tough3</a>. + I hope you have better, more sane, work days after that! + ^1 +Commit Often, Perfect Later, Publish Once: Git Best Practices</a> by Seth Robertson. +</div> + ^2 +Some clients I can think of: GitHub’s Git client</a> (free), Git Kraken</a> (free), Git Tower</a> (paid). +</div> + ^{3 +It will get tough, because source code management is not easy. Anyhow, it’s always tougher when you care about things anyway. Easiest thing is not to care about anything at all. +</div> +} Computer and Human Languages 2018-06-20T18:06:00+00:00 Basic knowledge of computer languages (mainly JavaScript) is assumed. + Some time ago, a friend of mine asked how skilled I’d say I was with JavaScript. I told him I was fluent. + – Fluent? What does it mean to be fluent? + – Well, think Portuguese. – We both speak Portuguese — I don’t know every word, but I do know the language enough to express anything I need somehow. + It turned out that “fluent” was just the perfect word. + +Fluency is a powerful and straightforward concept to express your ability with a language. When it comes to human languages, it’s the ability to fully communicate your intentions to a human; for computer languages, the ability to fully communicate your intentions to a computer. + That line of thought is shared in one of the most important and revolutionary introductory books to Computer Science. In Structure and Interpretation of Computer Programs, right before introducing Lisp (the programming language used throughout the book) a similar analogy is made: + +Just as our everyday thoughts are usually expressed in our natural language (such as English, French, or Japanese), and descriptions of quantitative phenomena are expressed with mathematical notations, our procedural thoughts will be expressed in Lisp. 1</a> +</blockquote> + For both kinds of languages, the levels are the same: one cannot communicate; can poorly do it (beginner); can do it (native/fluent), or can brilliantly do it (think book authors, public speakers, and Software Engineers in a senior level). + Why do they match so well?</h2> +They match because the linguistics of computer and natural languages wonderfully intersect. Both consist of syntax, semantics and pragmatics functions, found in the core of theoretical linguistics. + In their ecosystem, we can also find syntax trees and different style guides. +Syntax</h3> +Syntax is the set of rules that govern how language elements are combined to form a valid expression. +In English, the basic rule is that elements like nouns, verbs and punctuation marks must follow the subject-verb-object order</a> to produce a valid sentence. In JavaScript, a programming language, to produce a valid conditional statement, elements such as if</code>, parenthesis, braces, comparison operators (===</code>, <=</code> ) must be combined in a certain order too. + In the same way that “Do they car a put?” (??) is not valid English, the following code is not valid JavaScript: + if {1 === 2} ( + return true +) +// => SyntaxError: missing ( before condition + +add x y = x + y // u can't use elm's lambda syntax on js, no +</code></pre> +And just like a pedant friend would do when you write shitty English, the computer will throw a syntax error when running your program. Forgot closing a brace? Wrote an if</code> statement condition using curly braces instead of parenthesis? Well, SyntaxError</code>! + This, however, is valid JavaScript: +if (1 === 2) { + return true +} // "if (1 === 2) return true" is also fine! + +const add = (x, y) => x + y +</code></pre> +In HTML there are syntax rules too. Adding a div</code> inside ul</code>, for instance, is invalid. An unordered list in HTML (ul</code>) only allows list items as children, such as li</code> – and div</code> is not one. + Languages have different degrees of syntax strictness, which is what usually makes some harder to grasp than others. Think the German language – German imposes very strict rules for articles: they may vary in number, gender, and function. English, on the other hand, has a definite (the) and an indefinite article (a/an) – and that’s it. + The same applies to computer languages: some happen to be extremely strict when it comes to syntax, while others are designed for greater syntactic flexibility, letting you achieve the same result in different ways. Think semicolons: they are optional when ending statements in JavaScript, but mandatory in C. +Semantics</h3> +Semantics is what the language expression evaluates to. In human languages, expressions evaluate to thoughts, questions, answers; while computers evaluate expressions to CPU instructions that comprise a program’s flow. + Consider the following English statement: + +The ant ran over the car. +</blockquote> + I don’t know what ants you are familiar with, but even though the sentence contains the necessary elements in correct order and grammar, that doesn’t make sense. The statement is syntactically correct but semantically wrong – we can’t conceive a meaning from it. + (“The car ran over the ant”, however, would be definitely more acceptable to our ears.) + We can relate semantics to computer languages in several ways (like “solving the wrong problem”, basically), but the “semantic” word bubbles up more often when we think about HTML. Consider the following markup: +<span>What is a fruit?</span> +<div> + A fruit is something that humans eat. Some examples of fruits are: + watermelon, pineapple and apples. +</div> +</code></pre> +The elements span</code> and div</code> do exist in the language and are validly marked in this case (I didn’t do >div<</code>, right?), so the browser will understand and show it accordingly to the user. The syntax is correct; yet, span</code> and divs</code> are non-semantic elements, so computers won’t get any meaning from it. Again, syntactically correct but semantically wrong. + That text, though, is clearly a title and a paragraph. With a bit of HTML knowledge, we can communicate this in a meaningful way to computers! The language provides elements to achieve that. + The following code improves the previous markup for better semantics. +<h1>What is a fruit?</h1> +<p> + A fruit is something that humans eat. Some examples of fruits are: + watermelon, pineapple and apples. +</p> +</code></pre> +The element h1</code> is being used to communicate the main title, and p</code> communicates the paragraph. Both syntax and semantics make sense now! +Pragmatics</h3> +Pragmatics is what the language expression evaluates to within its interactional context – which might totally affect semantics and syntax. + In a natural language, the context is essentially built around the cultural aspects of the speaker, place, time, manner, and several others unpredictable aspects that humans introduce when communicating. + For computer languages, we can see pragmatics as the methodology or implementation used when approaching a problem: composition vs. inheritance, functional vs. imperative, picking a Design Pattern etc. + Consider the following examples: + +A child saying that the food is horrible to a beginner that started cooking just recently.</li> + A new joiner in the company filters items in an JavaScript array using forEach</code>, but the team expected filter</code> to be used – a more functional approach.</li> + A programmer implements Fibonacci with recursion instead of iteration.</li> +Your friend uses a very erudite language to add a cake recipe on the internet.</li> +</ul> +What do they all have in common? By themselves, they are neither right or wrong – unless you consider the context in which they were approached in. + Having either syntax or semantic skills won’t help you understand what’s wrong, since pragmatics is more about what’s appropriate within a context. Some approaches are more elegant, antiquated, or dialect-based than others, and we can only tell how valid they are considering what we are trying to achieve. + Syntax trees</h3> +Both kinds of languages can be represented using syntax trees, a concept that reuses the mathematical concept of partially ordered sets</a>. + Human languages are analysed through the Concrete Syntax Tree (“CST”), a context-free analysis that tells us about the function of each language token (word, punctuation etc) used. + This is the Concrete Syntax Tree for the previous sentence, “The water drank a glass of Mary.”: + </picture> +Concrete Syntax Tree for a sentence in a human language, where "S" stands for "sentence", "N" for "noun", "V" for "verb", and P for "phrase". See Wikipedia on Parse Trees</a> for more information.</figcaption></figure> +Computer languages are also represented using syntax trees! When the code (high-level) gets translated into instructions for the computer (low-level), a program called compiler make uses of them. The Concrete Syntax Trees for a program contains a lot of detailed information, from whitespaces to language expressions, so you can imagine a CST for a real-world JavaScript program as something really lengthy. + What compilers do might be tough to understand at first, but think of this program inside us that converts languages to meaning – our internal compiler. Kids improve their compilers while communicating with their families, so every day they get to understand their mother language even more. If you understand English yet struggle with German, we can say your German compiler is pretty bad and has to be improved. + The compiler simplifies the CST down to the expressions that truly represent the program after syntax analysis. That’s where the Abstract Syntax Tree (AST) comes in: the syntax tree that actually lies at the heart of semantic definitions! + Let’s consider the following JavaScript program: +let x = 0 + +if (x) { + x++ +} +</code></pre> +This is the Abstract Syntax Tree for it: +</picture> +Abstract Syntax Tree for a JavaScript program.</figcaption></figure> +It’s really about the essentials when considering language grammar. If a whitespace means nothing in a language, that won’t show up in the AST. +Compare that against a Concrete Syntax Tree for another program of similar size</a>, which is way more detailed, and therefore more useful in a language-specification level. + Style guides</h3> +When the same expression can be written in several ways because the language is not strict enough about it, style guides aim to answer the question of which style to go for. Curiously, style guides of writing are just as useful for programmers as they are for journalists! + Let’s say I’m telling someone my favourite fruits. I could do it in different ways: +My favourite fruits are watermelon, bananas and strawberries. + +// or using the Oxford comma +My favourite fruits are watermelon, bananas, and strawberries. +</code></pre> +The Oxford comma comes from the Oxford Style Guide</a>. + In JavaScript, you can write a JavaScript object</a> in different ways too: + const hero = { + firstName: "Ada", + lastName: "Lovelace", + birthYear: 1815, + superPower: "computers", +} + +// or comma-first style +const hero = { + firstName: "Ada", + lastName: "Lovelace", + birthYear: 1815, + superPower: "computers", +} +</code></pre> +Either way, there’s no definite rule. They mean the same, only changing their style of writing. +Some examples of style guides are Airbnb’s Style guide</a>, for writing JavaScript; and Chicago style guide</a>, for general writing. + Where they don’t match</h2> + +The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. […] Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. 2</a> +</blockquote> + Even with all the similarities, programming languages are still artificial, while human languages are natural. Computers are rigorous, won’t allow you to be ambiguous, and only get what you mean if you put it the right way. + You won’t have filler words in a computer language, because computers don’t benefit from your thought process. Humans do benefit, though, and I’d even say that those communication imperfections is what connects us to others. + Apart from that, a programming language is an interface between you and a computer, while a natural language is an interface between you and another human being. You are communicating to a computer, but as a human – and you probably won’t be the only one doing it. + Writing in a way that’s meaningful for both is therefore part of the writing process – and probably the most demanding one. + Final thoughts</h2> +Just like experienced programmers look at documentation and easily apply language features to create pieces of software, fluent English speakers would look at the dictionary and easily come up with phrases. + Because both computer and natural languages share linguistic structures, speaking about programming skills in terms of fluency works just as well. + After all, fluency is all about how easily our intentions are expressed with a language. + +As a next reading, I'd highly recommend Exploring the Linguistics Behind Regular Expressions</a> if you are interested in the linguistics of computer languages. + +Follow the discussion thread on Reddit</a> + ^{1 +“Programming in Lisp” in “Structure and Interpretation of Computer Programs”, 1979. +</div> + ^{2 +Fred Brooks. “The Mythical Man-Month: Essays on Software Engineering”, 1975, page 7. +</div> +}} React and Form Management: Is Redux Form Worth It? 2018-05-21T18:14:00+00:00 This is an improvement over my answer to a question in a Brazilian forum: "is using Redux for forms worth it?</a>", in Portuguese. It assumes previous knowledge with React and Redux, and also mentions Redux Form</a>, a library for managing forms in React. + It depends. + I know “it depends” is far from an interesting answer, yet that’s the perfect-generic answer to any “is using X worth it?” question. It really depends, yes, but more often you don’t need that. + Last year I picked Redux Form to build a multi-step form wizard, each step containing different forms, with its own fields and validations (some of them asynchronous!). In the end, all forms would be merged into one JavaScript object to be sent at some point. + So, I’d like to share my experiences and hopefully help you to figure it out what your problem is, and help you to decide by telling you how I’ve solved mine. + Where Redux Form thrives</h2> +Redux Form</a> is useful for larger and more complex forms where ease of development, high control (especially), consistency, and persistence (especially) are required. There are advantages from: + +the state form being in the Redux store, and</li> +Redux Form’s abstraction itself.</li> +</ol> +Which are two different things. You might need both, just one, or none at all. +Ease of development</h3> +Considering you are using Redux Form’s Field</a> and wrap your form in its higher-order component</a> – you’re done. Your form will work out of the box. + Yes, you could also get to build forms in a productive way with only React, but I think it's still worth-mentioning that Redux Form makes it really painless. + High control</h3> +You can manipulate forms from anywhere in the application: you trigger Redux actions provided by Redux Form and that’s all. No need to create your own Redux reducers and actions. + Redux Form is also flexible on what can be an input. Anything works as a field: custom 3rd-party inputs, a regular HTML input, a fancy select component without any standard form element at all… Just pass the right props to it. + You can set up validation at the form and field level, supporting either synchronous or asynchronous validation. The errors triggered are also in the store – which makes it sweet to give useful feedbacks for users from anywhere, and also to debug! 👌 +Consistency</h3> +All forms have the same data structure so you’d have the exact same information for every form and its fields, such as field values, field/form validity and further information (is the field touched? Pristine? Dirty?) in the Redux store. + Of course you can build forms consistently just by using React itself, but using Redux Form definitely enforces it. +Persistence</h3> +Since the state is already in the Redux store, Redux Form is easily pluggable with tools from the ecosystem. +Let’s say you want to save drafts from user’s inputs so people can finish and submit the form later. Redux Form + redux-persist</a> make it pretty easy: the rehydrate process in the Redux store autofills the UI like magic! + Where Redux Form might die</h2> +In the thread, someone mentioned the article Redux Form is dead.</a> TL;DR: It's not fucking dead, as any library, framework and whatsoever that has an "X is dead" post for it. + Let’s not forget that the JavaScript community is flooded with “X is dead” articles for everything in the ecosystem. That post, in particular, mentions valid points to consider such as ephemerality of the state (quoting Dan Abramov), performance issues within Redux Form, and the project maintenance/activity. I will go through them a bit. + Form data in the Redux store</h3> +Dan Abramov</a>, creator of Redux, said</a>: “Use React for ephemeral state that doesn’t matter to the app globally and doesn’t mutate in complex ways. For example, a toggle in some UI element, a form input state. […]”. + Which is completely accurate. Where your state should live in your app depends entirely on its ephemerality – how trivial it is for the application as a whole when it comes to reading, updating it and so on. + In the post, that quote is used to support the claim that Redux Form fucks up when stores all form data in the Redux store by default – a pretty bold design decision for sure. + However, Dan did not write that in stone – he never does and he’s clear about it. That should serve as an encouragement for developers to think better about where your application’s states should go into. So, yes, you should think twice – and that doesn’t kill Redux Form. + The state of a form wizard, whose input data persists until the end of the steps (in a session or local level, for instance), whose inputs may trigger UI changes, whose inputs gets touched and changed by external components, it’s definitely not as ephemeral as the state of a newsletter sign up or a contact form. In the former, the form state is important for the whole application. Just notice that’s a very specific case. + Performance issues</h3> +Redux Form has reached a well-optimised (see redux-form #529</a> and redux-form #1405</a>) state. + When it comes to performance, though, you should never rest easy anyway. If you measure and find that your forms are slow, you should find bottlenecks and optimise from that. + Project activity</h3> +Regarding the project activity, it is something to consider when deciding, and should always be. Is it active? Are there people maintaining it? Can YOU help to maintain it? +Yes, Erik (the author) has recently started working on another solution called Final Form</a>, which moves the form state out of the Redux store. However, Redux Form is mature, still well maintained (check GitHub</a>, and he even said it himself on Reddit</a>), and its documentation is great. + Final words</h2> +Only if the state of your form is non-trivial enough to live in the Redux store, I’d give it a chance for Redux Form, especially if you are considering making your own solution. Redux Form has suffered and evolved a lot and nowadays it has a very stable and mature API you can count on, I’d say. +Other React form management solutions you should definitely be looking at are Formik</a> and react-final-form</a>, by Redux Form’s author. They don’t rely on Redux for state management and are most likely what you need now – or not. + The price is the abstraction, of course, it always is. 🙄 However, their everyday API is indeed minimal though, just be prepared to go through the documentation when you need to achieve specific stuff. In return, don’t forget you’ll get a consistent and solid structure to build forms upon. + Have fun building forms! 🎉 + T. T. T. 2018-04-01T23:36:00+00:00 +Put up in a place +where it's easy to see +the cryptic admonishment + T. T. T. +When you feel how depressingly +slowly you climb, +it’s well to remember that + Things Take Time. + + Piet Hein + Writing Mode in VS Code 2018-02-28T02:30:00+00:00 I’m a big fan of writing. I’m also a big fan of using my code editor and Markdown for that! + +My "writing mode" in VS Code, with the dark theme enabled.</figcaption></figure> +Code editors are usually packed with a bunch of useful features, such as multi-selection, syntax highlighting, a file tree easy to operate, and sometimes even Markdown support</a> – which I need for writing my articles, notes, to-do lists, and absolutely everything I can write using Markdown. I love having a consistent workflow and that’s crucial to me, so why not? + After configuring my editor of choice, VS Code, to get rid of the coding mode clutter (and also after an important update on its zen mode</a> ❤️), I’ve finally achieved a totally distraction-free writing experience! + Setting up the “Writing Mode”</h2> +1. User Settings</h3> +There are some important details to achieve total focus on writing. No line numbers, word wrap enabled, comfortable line height, no rulers, are some of them. + Since I only write in Markdown, I only set up those settings (and other tweaks) specifically for that language. +// github.com/diessica/dotfiles/blob/master/vscode/settings.json +{ + .... + + "[markdown]": { + // force centering in zen mode + "zenMode.centerLayout": true, + // use the beautiful duospace font when available + "editor.fontFamily": "iA Writer Duospace, monospace", + // enable word wrap, since horizontal scroll while writing isn't human + "editor.wordWrap": true, + // i don't need line numbers, i'm not coding + "editor.lineNumbers": "off", + // light by default, but can be easily toggled to dark + "workbench.colorTheme": "Default Light+", + // i don't need rules, i'm not coding + "editor.rulers": [], + // larger text, to improve focus on writing + "editor.fontSize": 14, + // more comfortable line height + "editor.lineHeight": 25, + // disable editor suggestions based on previous words + "editor.quickSuggestions": false, + }, + + ... +} +</code></pre> +You can learn more about this file by checking the docs on "User and Workspace Settings"</a>. + Now, toggle zen mode in VS Code (see Keybindings</a>, or View > Toggle Zen Mode</code>) and check if that fits you! + 2. Theme</h3> +Honestly, I think the default themes provided by VS Code do a great job. I use Dark+ as the dark theme; for light themes, either Quiet Light or Solarized Light. + If you don't like them, feel free to pick anything else, since most themes provide sufficient Markdown support anyway. Just don't procrastinate – a good theme won't make you a better writer. +3. Font</h3> +My font of choice for writing is the Duospace</a>, designed by the people behind the text editor iaWriter</a>. It’s a free and beautiful font shaped for the perfect writing experience. + 4. Extensions</h3> + +Spell Checker</a> catches your spelling errors.</li> + Word Count</a> helps you to not to be too wordy.</li> + Markdown All in One</a> gives you some extra power to play with Markdown files.</li> + Paste Image</a> lets you directly paste images from clipboard to files.</li> +</ul> +Extra tips</h2> + +VS Code’s Markdown Preview</a> is your friend – use it when you’re done with writing!</li> + Configure the spell checker for your language, there are dictionary extensions for that available in the marketplace</a>. I also have the Brazilian Portuguese package</a> installed, for instance.</li> + Like extensions? Keep exploring! The extension alex</a>, for instance, catches insensitive, inconsiderate writing in texts.</li> + Learn the Markdown keybindings provided by the All in One extension for a better workflow.</li> +</ul> +Happy writing! 🌟 + My Hacking Adventure in Lithuania 2018-02-15T00:00:00+00:00 +Exploring the country where my surname came from and hacking collaboratively at Science Hack Day Vilnius! +</div> + I love to hack stuff, and, this year, I’ve been pushing myself to do more of that along with people. +That’s how I found a hackathon called Science Hack Day, a weekend event with the goal of “making weird, silly or serious things with science”1</a> in collaboration with others. Although I missed the Berlin edition for just a few days after it happened in November, another event was about to come – this time, in Lithuania, where my surname “Gurskas” came from. + There it was the perfect replacement: the Science Hack Day Vilnius 2018</a> would be my great excuse to explore the country where my grandfather was born. + Right on the last minute, I got a bedroom in a cheap hotel booked, and my flight and event tickets ready. All set for the hacking adventure! + Welcome to Vilnius</h2> +Approximately 2 hours from Berlin by plane, there I was: Vilnius, the capital of Lithuania. A modest city, so small you can pretty much explore everything by feet. + Temperatures were more negative than in Berlin. Winter, and the city wasn’t the most colourful either, so the atmosphere was somewhat dark – even though the snow was painting all buildings, houses, and streets in a shining white. + The cold was totally dismissible as soon as I met the Lithuanians, warm and welcoming people who seemed to lead a simple life. +Science Hack Day Vilnius 2018</h2> +</picture> +Trophies for different prize categories. (Photo: Raitis Gocentas</a>)</figcaption></figure> +A Science Hack Day is a 2-day event run by volunteers. Since it’s a hackathon, it’s pretty hectic and leaves you exhausted at the end. However, also since it’s a hackathon, it’s remarkably rewarding at the end. + These were my days! +First Day</h3> +Early on Saturday, I walked to Technarium</a>, where the event would happen. It’s a laid-back and community-operated hackerspace in Vilnius, where technology enthusiasts work or co-work on their projects and share knowledge. My perfect habitat, sort of. + </picture> +Technarium. (Photo: Raitis Gocentas</a>)</figcaption></figure> +I found a seat in the middle of a diverse crowd of enthusiasts: kids, teenagers, and adults (in which you could also find scientists and professors). I had forgotten to adjust my clock to the local timezone when I arrived in Lithuania – 1 hour ahead of Berlin –, so I was kinda late and the talks on open science had already started. + With honestly no idea on how all that’d end up (a feeling I’m used to, since I always do unexpected stuff to myself anyway), I was watching the talks and telling myself that the worst that could happen was that I’d have no idea and no team, and would end up just exploring what others were building. It didn’t sound any bad at all! Being around creative people is always appreciated anyway. +</picture> +Electronic hackable badge and some stickers I got for joining the event! The badge features a WiFi-enabled micro-controller and MicroPython, for some hardware hacking fun. Check the badge's GitHub repository</a>.</figcaption></figure> +After the talks, it was time for people to pitch about their potential projects. Most ideas involved Biology, Programming, Physics, Chemistry – anything related to (science) hacking! One of the ideas, from a team of 3 guys, was to build an audio visualiser. + “We need a Python engineer who understands some audio engineering”, they said, in Lithuanian (thanks person who was real-time translating everything!). Luckily, in a beautiful coincidence, I love music, Python, and also have been playing with spectrum analysis for audio visualisation in the last year – so I decided to take a shot and ask them to join the team. + They said they had no idea how to get the input from a microphone, and that they knew more about the hardware part, Arduino, and manipulating those machines in the hackerspace to come up with a cool design for our project. I’m just bad at things that require manual work that isn’t with the keyboard, so my manual help would be typing Python for 2 days on my laptop. They accepted it. So far, we had: + +the idea;</li> + an Arduino Nano;</li> + a power supply;</li> + long LED strip lights;</li> +an acrylic sheet.</li> +</ul> +Since Arduino Nano isn’t powerful enough for that computation, it’d be only used for data acquisition, and the spectrometer would live in our Python program in my laptop, computing the Fourier transform of the audio signals. +By the end of the day, we managed to get input from the microphone, analyse its signals in the frequency domain with Python, and start mapping that data to be sent to our Arduino over a serial interface. Some libraries we played with were: pyaudio</a>, numpy</a>, pyserial</a>, matplotlib</a>. + Second Day</h3> +Now with the clock correctly set (thanks to my friend that asked what timezone I was in, otherwise I wouldn’t ever know), I was on my way to Technarium again, walking over and under snow in that early Sunday morning. +A day in the Science Hack Day Vilnius was a day with Lithuanian hearty lunch, black coffee, and hard work around kind people. (By the way, if you ever end up there, try the kibinai</a> – I ate one filled with spinach and will never forget how it smelled and tasted.) + Most people there were Lithuanians and I didn’t know anything about their language besides “labas vakaras”2</a> (“good evening”), so I felt like an outsider sometimes. My teammates and other Lithuanians in the event – including kids –, though, were friendly and spoke English flawlessly, and fortunately even translated some stuff into English for me. + Curious fact: A teenager at the event told me that my surname was "wrong" – in Lithuania, single women get a different surname suffix, so my name should be Gurskaite ("skaite" suffix, instead of –kas). In Brazil, of course, they didn’t know that and only cloned my grandfather’s surname – with the "kas" suffix, since he was a man: Gurskas. + More talks in the morning on open hardware and software. They introduced everyone to GitHub, and many people, even students, were already familiar with it. The importance given to open source was impressive! That made me really happy. + Time flew on the second day! We had got the data we needed, and the next step was to decide on what would be more fun: to map amplitudes from the maximum frequency to RGB values for all LEDs, or map each LED to a frequency and change its colour depending on the amplitude? We picked up the latter, and got our LEDs to blink. + +One of my teammates was learning Programming. He told me he didn’t know what programming languages to really sit down and learn, as seen that there were a lot of them out there. True, and a nice question! I gave him a biased answer, of course: “go for Python or JavaScript”. My reasons? Way more fun. Besides beginner-friendly, those languages have the most interesting, welcoming and lively ecosystems I know these days. + +We were running out of time. While 2 of my teammates were building the LED tower, the other and I were testing the code and trying to improve our algorithm, everything at the same time. Eventually, we got our LEDs to blink the way we wanted them to, and the clock pointed 18:00 sharp. Time for presenting! +</picture> +Project showing how lasers work. It emitted sounds too! (Photo: Raitis Gocentas</a>)</figcaption></figure> +Teams came up with a lot of cool things! Projects related to lasers, contactless payment systems security tests, shopping-cart-rocket launch</a> (#SpaceXLithuania!), plant-watering automation, posters with LEDs crafted by kids celebrating the 100th year of the Lithuanian as an independent country… And ours, of course. + </picture> +Two of my teammates (one's missing!) and me. I was weirdly concentrated uttering different notes to show how LEDs reacted to frequencies. (Photo: Raitis Gocentas</a>)</figcaption></figure> +There were different category prizes, and we won as the Best Data Hack! + I got the honor to take home not just this LED-powered trophy below, but also a memorable experience I had the pleasure to share with people I didn’t know in a country I didn’t know. +</picture> +A trophy for the Best Data Hack 2018 and a Raspberry Pi. Our prizes for having fun!</figcaption></figure> +The Hack Day ended with a science show by N2</a>! Lots of fun with liquid nitrogen and eating cookies at temperatures close to the absolute zero. My teammates, Physics students, knew a lot of the science behind that stuff so I got some extra explanations! (I have to say, though, that one of my greatest learnings of that day was to not to chew those cookies slowly – they stick to your tongue in a TORTURING way.) + </picture> +Playing with fire. Literally. (Photo: Raitis Gocentas</a>)</figcaption></figure> +It’s always truly amazing to experience closely how creative and curious humans are! The event was awesome, well-organised, and, last but not least, fun. Organisers provided us all the materials (food included!), borrowing me even the single USB-C adapter they had! + Clearly, the only intent behind Science Hack Days is for people to share and learn openly. And that has been achieved just right. +Final words</h2> +Open knowledge is one of the most valuable things in this world. I have no doubt. + I’m happy to have picked such an eccentric travel destination for my weekend, and really grateful for everything I saw and everyone I’ve met on the way. +</picture> +I don't feel my fingertips anymore since I did that. Writing in the snow: definitely NOT encouraged!</figcaption></figure> +Lithuania was freezing, yes, but people were warm. +^1 +From the Science Hack Day’s Wikipedia page</a>. +</div> + ^{2 +Special thanks to my father, who taught me that, otherwise I wouldn’t know anything really. +</div> +} Creativity 2018-02-05T21:25:00+00:00 In a life where, by default, there’s no meaning at all, I value creating above all. If I’m creating, that’s a meaningful day. + Lately, I’ve been pondering on the phenomenon of creativity and why creative people are so inspiring to be around. They just broaden my perception of the universe profoundly. What really happens? +The Phenomenon</h2> +In an interview in the late 1990s1</a>, Steve Jobs said something that years later would be seen as one of the most simple but accurate definitions of creativity: + +Creativity is just connecting things. +</blockquote> + And he followed with something I couldn’t help but relate: “When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while. […]”. + In the wake of being called creative, I was used to responding with the most unfair answer ever: “But everything I did was mixing stuff from here and there!?!“. It turns out, however, that “mixing stuff” actually describes precisely the process creative people go through. +And when Steve Jobs said that, he was mixing stuff as well! He most likely got inspired by James Webb Young’s conception of idea, presented in his book A Technique for Producing Ideas</a>, from the 1940s. + +An idea is nothing more nor less than a new combination of old elements [and] the capacity to bring old elements into new combinations depends largely on the ability to see relationships. +</blockquote> +For James to suggest that, well, guess what? He was inspired by Pareto</a>'s idea of the "speculator", a personality type characterized by a constant preoccupation with the possibilities of new combinations of old elements. (Which sort of proves his own point on "ideas as a combination of old elements".) + Creatives are just so overloaded with elements to mix that those overflow and flow out of their heads, and they can’t help but inspire everyone around. + They reframe experiences and mix their elements to be synthesised into something valuable and unique. From songs, painting, programming to scientific theories – all of them comes from mixtures. When the mixture feels good, either as a homogeneous or heterogeneous result, it’s then a creation. + The Creation, The Weird</h2> +</picture> +Creativity</a>, by Alex Norris.</figcaption></figure> +When the creation distances itself too much from its origin elements (which are things people are already aware of, most likely), it’s perceived as weird, rather than authentic. But that’s when we truly innovate! To come up with the weird, though, we have to limit ourselves to certain existing elements – an outstanding habit people like Alan Turing had. +Alan Turing was an inspiring computer scientist. Among other cool stuff, he proposed humans to consider the question "Can computers think?"</a>, and also designed cryptanalytical machines</a>, crucial to cracking German encoded communication during the World War II. Cool stuff! + As described by James Wilkinson, who worked closely with him, Turing avoided looking at previous work on a topic just so he could invent something truly original, truly weird. + ”Turing had a strong predilection for working things out from first principles, usually in the first instance without consulting any previous work on the subject, and no doubt it was this habit which gave his work that characteristically original flavor.“ 2</a> + Finally, the ones who release their creations end up turning into painters, mathematicians, writers, architects, sculptors, programmers, musicians. It’s a process that happens in absolutely every realm of thinking and work. + And you know what? + …It’s Been Shown by Nature</h2> +When Young and Steve Jobs pointed out that the creative process wasn’t magic, they, again, didn’t do anything “new” either. That definition has been shown by Nature for a long time, and, as early as 450 B.C, the philosopher Anaxagoras</a> described it: + +Wrongly do the Greeks suppose that something3</a> begins or ceases to be; for nothing comes into being or is destroyed; but all is an aggregation or secretion of pre-existing things; so that all becoming might more correctly be called becoming mixed, and all corruption, becoming separate. +</blockquote> + That might remember you of the Law of Conservation of Mass, later defined by the chemist Antoine Lavoisier. + Just like in the creative process, Nature has always found a way out of its problems by coming up with solutions from pre-existing elements. Even the Planet Earth has transformed from a violent, molten rock to a supporter of life by using what the Universe had already provided! + Its process of creation was the same as the human’s creative process for the discovery of fire, the invention of the wheel, shitty and useful startup ideas, the Pink Floyd’s Echoes song, and all quotes in this post: mixing, connecting, combining “stuff”. From the Planet Earth to what you’re reading right now, the laws that ruled their creations were, in essence, the same. + ^1 +Steve Jobs. “Steve Jobs: The Next Insanely Great Thing”</a>. WIRED. January 1996. +</div> + ^2 +James H. Wilkinson, “Some Comments from a Numerical Analyst”</a>, 1970. Turing Award</a> lecture, Journal of the ACM. February 1971. +</div> + ^{3 +I’ve deliberately changed “aught”, an archaic English word, to “something” for the sake of readability. +</div> +} Dental Health and Habits 2017-12-21T08:58:09+00:00 Brushing teeth is a good habit. An easy-to-build one, I’d say, thanks to the immediate reward given by the refreshing sensation. After brushing, you feel clean right away. + On the other hand, flossing teeth isn’t a habit as easy to build. After flossing, what comes to mind is how dirty your teeth still were even though you just brushed, not how cleaner they became. There’s no such thing as a fresh sensation in your mouth. + When you finish brushing your teeth, they’re still dirty – no doubt. However, it’s still gratifying, since you’re fooled by the menthol ability to trigger the cooling sensation. (Hence the human inclination to brushing rather than flossing!?) +In terms of dental health, though, flossing teeth is more effective on cleaning than brushing1</a>, even if it doesn’t feel like it. There’s no immediate reward in flossing, but definitely a long-term one. + What am I trying to say? Apart from dental health advice, that sort of reminds me that we shouldn’t rely on feeling instantaneously compensated as a fuel to build habits. After all, some things just need the long-term to pay off; for we to benefit from them. + ^1 +I’ve read that at some point in my life but don’t remember where. You can find some resources out there, such as “What’s More Important: Flossing or Brushing?</a>”. Anyway, I think we’re safe assuming that flossing is, at least, as important as brushing. +</div> + Expressive JavaScript Conditionals (for Humans) 2017-10-30T00:00:00+00:00 Conditionals! As programmers, we write at least one every day. Easy to write, horrible to read, and sometimes it seems as though there’s no way to work around that. + Today, I’m happy to share some patterns I’ve learned over time and have spread heavily in code reviews. Let’s rethink conditionals to make the most out of a language’s power of expression – in the case of this article, JavaScript. +Patterns for Conditionals</h2> +First, to put you in the mood, a quote from Literate Programming1</a>, by Donald Knuth. + +The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other. +</blockquote> + That sums up the approach for this post: purely aimed at how to write code for people to read. Performance doesn’t matter now, since 1) that’s not the goal and 2) I don’t believe in premature optimisation. + I’ll briefly talk about each pattern, but what’s more important here is to read the code carefully and get something out of it (as if it were poetry or something!). +1. Variables that hold conditions</h3> +When your condition is made up of an expression (or many of them), you can store it within meaningful-named variables. + Let’s say, to illustrate, that our program holds some data about a fruit and we have to check whether that fruit is a banana. We could do this: +const fruit = { + colors: ["yellow", "green"], + sweet: true, +} + +if (fruit.sweet === true && fruit.colors.some((color) => color === "yellow")) { + alert("do your stuff 🍌") + return "is banana" +} +</code></pre> +Or we could store our conditions in variables! +const fruit = { + colors: ["yellow", "green"], + sweet: true, +} + +const isSweet = fruit.sweet === true // or just `fruit.sweet` +const isYellow = fruit.colors.some((color) => color === "yellow") +const isBanana = isYellow && isSweet + +if (isBanana) { + alert("do your stuff 🍌") + return "is banana" +} +</code></pre> +Not all conditions need to be in a variable. fruit.sweet</code>, for instance, is quite expressive by its own. + This way, if we or our workmates need to know what makes a fruit a banana in our program, it’s just a matter of checking out the variable itself. The logic for how conditions evaluate will be there, behind a meaningful name. + It’s even more useful for composing and reusing conditions. +Filtering arrays</h4> +In the previous example, all variables were conditions based on the fruit</code> object, for didactic purposes. Commonly, though, those variables actually store (pure) functions that take any fruit and test against it. I'm changing that to fit this example. + Let’s say we’ve got an array of fruits and we need to filter all the bananas out of it. +const fruits = [ + { + colors: ["yellow", "green"], + sweet: true, + }, + { + colors: ["red"], + sweet: false, // don't know what kind of fruit this'd be + }, +] + +const isSweet = (fruit) => fruit.sweet === true + +const isYellow = (fruit) => fruit.colors.some((color) => color === "yellow") + +const isBanana = (fruit) => isSweet(fruit) && isYellow(fruit) + +const bananas = fruits.filter(isBanana) +</code></pre> +So expressive! I love the way that I can read that last line and even a kid (a non-programmer one!) can understand. (Yes, I’ve tried that.) + The currying technique would help introduce expressiveness without the verbosity for isBanana</code>. An optional appendix at the end of the article elaborates more on that, if you’re curious. + That’s it. Hold on to that one though – it’s the foundation for what’s next. +2. Define value conditionally</h3> +Still considering the variables from the example above, this could also be done: +const myFruit = isYellow && isSweet && "banana" +return myFruit +</code></pre> +The value for the myFruit</code> variable will only be assigned to “banana” if those conditions are true. Pretty useful for when values are defined conditionally! + That saves you from if (isYellow && isSweet) [...]</code>, and it’s quite expressive, I’d say. An expressive expression. 👌 +3. Define value conditionally with fallback</h3> +</picture> +xkcd: Conditionals</a></figcaption></figure> +What if we want something else in case it’s not a banana? Instead of an if (isBanana) [...]</code> with else</code>, go for the ternary operator</a>. + const isBanana = isYellow && isSweet +const myFruit = isBanana ? "is banana" : "is other stuff" +return myFruit +</code></pre> +Some additional but important advice I’d give regarding ternary expressions: + +Make them as compound as possible.</li> + Do NOT nest them. Don’t pretend the nesting is readable – it’s not even human to do that.</li> +Don’t avoid writing if</code> statements because you want to look smart.</li> +</ul> +4. Check for all conditions</h3> +We’ve (finally) found out that checking for isYellow</code> and isSweet</code> isn’t enough to make sure the fruit is a banana. After all, yellow pepper is both sweet and yellow and it’s still not a banana, right? + Right. We then add more checks to the isBanana</code> variable, and this time they’re ugly ones: they check whether the fruit is either from Brazil or Ecuador, both top banana producing countries. +const fruit = { + colors: ["yellow", "green"], + sweet: true, + countries: [ + { + name: "Brazil", + topProducer: true, // i'm brazilian and therefore biased + }, + { + name: "Ecuador", + topProducer: false, + }, + ], +} + +const isSweet = fruit.sweet === true // or just `fruit.sweet` +const isYellow = fruit.colors.some((color) => color === "yellow") +const isBrazilian = fruit.countries.find((i) => i.name === "Brazil") +const isEcuadorian = fruit.countries.find((i) => i.name === "Ecuador") +const isBanana = isYellow && isSweet && isBrazilian && isEcuadorian + +if (isBanana) { + alert("do your stuff!11 🍌") + console.log("now this is really a banana") +} +</code></pre> +Did you see how big isBanana</code> is getting? We’d have to start breaking lines in those &&</code> to improve readability, which, personally, I don’t like doing. + If refactoring the booleans into new variables isn’t an option anymore, what about storing the conditions in an array and testing every item for truthiness? +Use the power of array’s every</code></a>: + const isBanana = [isYellow, isSweet, isEcuadorian, isBrazilian].every(Boolean) // or `x => x === true` +</code></pre> +Repetitive friendly reminder: don't store every condition in a variable. Remember you can always add the condition itself to the array. + You can even turn that into a snippet: +const all = (arr) => arr.every(Boolean) + +const isBanana = all([isYellow, isSweet, isEcuadorian, isBrazilian]) +</code></pre> +I don’t know how useful that looks for you, but, in everyday work, I really appreciate doing it. +5. Check for any condition</h3> +What if we’ve got crazy and we’re fine considering something a banana when it’s either yellow, Brazilian or sweet? +Use the power of array’s some</code></a>: + const isBanana = [isYellow, isSweet, isBrazilian].some(Boolean) // or `x => x === true` +</code></pre> +Yeah, yeah, I know, you can just use the OR operator</a>. + If any of them evaluates to true, profit! – it’s a banana. 🍌 + const any = (arr) => arr.some(Boolean) + +const isBanana = any([isYellow, isSweet, isBrazilian]) +</code></pre> +In other words, being a Brazilian means you’re a banana! It doesn’t sound any bad to me honestly. +Pretty similar to Ramda’s either</code></a>. 😎 + 6. Early return</h3> +We want something special for when the banana is Brazilian! else</code> conditions would do the trick, wouldn’t they? +const fruit = { + colors: ["yellow", "green"], + sweet: true, + countries: [ + { + name: "Brazil", + topProducer: true, // i'm brazilian and therefore biased + }, + { + name: "Ecuador", + topProducer: false, + }, + ], +} + +const isSweet = fruit.sweet === true // or just `fruit.sweet` +const isYellow = fruit.colors.some((color) => color === "yellow") +const isBrazilian = fruit.countries.find((i) => i.name === "Brazil") +const isEcuadorian = fruit.countries.find((i) => i.name === "Ecuador") +const isBanana = isYellow && isSweet + +if (isBanana && isBrazilian) { + // first true case! + alert("i am a brazilian banana i love football 🍌") +} else if (isBanana && isEcuadorian) { + alert("i am an ecuadorian banana do not mess with me 🍌") +} else { + alert("a normal banana from somewhere else") +} +</code></pre> +Alternatively, THOOOUGH, we can early return (nothing at all, i.e. undefined</code>), which will make our code stops its flow at that point. +if (isBanana && isBrazilian) { + alert("i am a brazilian banana i love football 🍌") + return // sTAAAAHP!!!1 +} + +if (isBanana && isEcuadorian) { + alert("i am an ecuadorian banana do not mess with me 🍌") + return // DON'T GO ANY FURTHER, JAVASCRIPT!11 +} + +// or do, whatever +alert("a normal banana from somewhere else") +</code></pre> +Those checks could also be refactored into a variable named isBrazilianBanana</code>. I found it too much for this example though, so this is just a friendly reminder that your conditions can always be composable. + Keep in mind that early returns might make the flow of your program confusing. Different from when you’re using else</code> conditions, it’s not explicit that the conditionals are from the same logical group anymore. +7. Check for the same variable</h3> +Let’s get the colour of the fruits! Each fruit has one. + Hmmm… Different cases that require different handling, but all handled cases depend on the same thing. What do we do? We conditionally check for its value and handle the case depending on that. +const getFruitColor = (fruit) => { + if (fruit === "banana") { + return "is yellow" + } else if (fruit === "apple") { + return "is red" + } else if (fruit === "orange") { + return "is orange" + } +} + +getFruitColor("banana") // => is yellow +</code></pre> +This code would benefit from early returns, and, of course, the switch</code> statement. + Or we don’t. Because, alternatively, we can create a getter function (getFruitColor</code>) that: + +inputs a key (fruit</code>), and</li> +outputs the value that was assigned to that key in a specific map (fruitColors</code>).</li> +</ol> +Like this: +const fruitColors = { + banana: 'is yellow' + apple: 'is red', + orange: 'is orange', +} + +const getFruitColor = fruit => fruitColors[fruit] + +getFruitColor('banana') // fruitColors['banana'] => is yellow +</code></pre> +Simplifying, since that map isn’t useful outside of the getter itself anyway: +const getFruitColor = fruit => ({ + banana: 'is yellow' + apple: 'is red', + orange: 'is orange', +}[fruit] + +getFruitColor('banana') // => is yellow +</code></pre> +This is a very common technique I first saw on a blog post from Angus Croll</a> in 2010. I love the simplicity of it. + Nowadays there’s even more freedom with this technique, considering features such as computed property names for objects</a>. But don’t get too creative with that! Go for what’s more readable and expressive for you AND the people you work with. + Appendix: Currying, because verbosity isn’t expressiveness</h3> +This is an additional reading and requires familiarity with curried functions. For further reading on the currying technique, I recommend the "Currying" chapter</a> of the book Mostly Adequate Guide to Functional Programming, or A Beginner’s Guide to Currying</a>, as a more beginner-friendly introduction. + Let’s reconsider: + +the problem from the 1st, where we had an array of fruits and had to create a function that checks whether the fruit passed to it was a banana, and</li> +the all</code> util from the 4th pattern.</li> +</ol> +Check for all conditions, revisited</h4> +Imagine if we had a lot of conditions for isBanana</code>. We could use &&</code> or even all</code>. +const isBanana = (fruit) => + isBanana(fruit) && + isSweet(fruit) && + isEcuadorian(fruit) && + isBrazilian(fruit) +// or +const isBanana = (fruit) => + all([ + isYellow(fruit), + isSweet(fruit), + isEcuadorian(fruit), + isBrazilian(fruit), + ]) +</code></pre> +It’s meaningful, easy to read, but introduces too much verbosity. The currying technique could help us introduce more meaning without being verbose. With some changes in the all</code> util, that could be boiled down to: +const isBanana = all([isSweet, isYellow, isEcuadorian, isBrazilian]) +// no explicit fruit here, and still works! +const bananas = fruits.filter(isBanana) +</code></pre> +Notice we’re not explicitly passing fruit anymore. How do we do that? By making all</code> a curried function. There are some ways to achieve that, here’s one: +const all = (conditions) => (currentItem) => + conditions.map((condition) => condition(currentItem)).every(Boolean) +</code></pre> +It takes the array of conditions and returns a function that takes the current item and calls each condition with that (as argument!). At the end, we check whether they all evaluated to true. It’s not magic, it’s CURRYING!!!112</a> + That’s, of course, a simplistic implementation, which has costed me an array (from map</code>). What’s important to get is how we play with function arguments under the hood to achieve currying. + You can curry your functions using Ramda’s curry</code></a> (or Lodash’s, whatever); or, if you’re interested on that as an util, Ramda’s all</code></a> and its source</a> are really worth-checking! + Final considerations</h2> +By striving for conditionals as expressions other than statements, you write code in a functional approach. Code with a clearer sense of what it’s being checked without having to unearth to its foundations. Code that’s easier and faster for people to reason about. + But if your code is fine with an if</code> rather than an object lookup or a ternary operator, just stick to it. + It’d break the whole purpose of this post if those patterns were used for looking smart. However, if refactoring your conditionals with them would lead to a more expressive codebase, go for it! Play with the patterns, compound them. Use your creativity to communicate well. + It’s a language, after all. +^1 +A programming paradigm first introduced by Donald Knuth, with the goal of providing an alternative, human, perspective on the programmer’s motivation. Read the article</a>. +</div> + ^{2 +It may seem more magic than currying sometimes. JavaScript isn’t a purely functional language, so such techniques aren’t as popular as they are in Haskell community, for instance. Simplicity conflicts with easiness here. +</div> +} UI Components that Abstract Mistakes 2017-10-14T18:06:00+00:00 2017, October 14th. +A cloudy day 1</a> of Autumn in Berlin, probably something else in the place you live, and you’ve read the same date twice and this introduction actually doesn’t matter. But let me tell you about something that matters. + Everything is made up of <div></code>s and </code>s again, utterly hidden behind abstractions proudly called components. No one seems to remember (or do they?) the difference between p</code> and span</code>, let alone the point of using section</code> rather than div</code>. + Bad decisions – to not just to say bad and even invalid HTML markup – are buried in components developers find awesome to compose user interfaces with. The web, and people, pay the price. + +Creating components</h2> +From now on, to explain my point, I'll be assuming some familiarity with React</a> (a JavaScript library), although this applies to any kind of component abstraction. + Let’s say you just started a brand new React web app. You need to create a button at some point, and, because it’s reused in other parts of the app, has custom styles and also a fancy icon, you decide to introduce a component with all that abstracted out. Nice! You could do it like this: + const Button = ({ onClick, children }) => ( + <span class="my-horrible-button" onClick={onClick}> + <i class="my-terrible-font-awesome-icon"> + {children} + </span> +) +</code></pre> +The user interface is then composed as the following: +<h1>Brazilian Bananas (1 kg)</h1> +<p>Sweet and healthy bananas!</p> +<p>Absolutely the best.</p> +<Button onClick={() => alert('🍌')}>Buy $0.99</button> +</code></pre> +It looks good! You were born for this, weren’t you? + Quite easy to miss what’s wrong when components are just used like that. A button, isn’t it? The engineering team can easily grasp what that means and what that does, after all. + It could also be a <FormLabel /></code> or <Paragraph /></code> as span</code> elements, or div</code>s all over that place. Although they all work, mistakes are abstracted in components. + I specifically talk about markup as the mistake throughout this article, however it could be anything really. Components look inoffensive when you're using them. +The web isn’t your abstraction</h2> +Now that HTML is all abstracted through JavaScript libraries and frameworks (which is not wrong), I wonder whether developers only went for semantic elements for the sake of making markup more readable for themselves. With React, your <Header></code> now may be a div</code>. Out of the abstraction, though, you’d think twice before going for a div</code> to make a header – you’d rather use HTML5’s header</code>. + Because of the abstraction, output markup isn’t something we talk that much about anymore. +Did we really get the benefits of HTML5 and why new elements were introduced? Why button</code>? 2</a> What’s header</code> useful for? Why should one use section</code> at all? + By the way, do you know how many occurrences of header</code>, article</code>, section</code> I've found on Netflix's landing page? Zero. It's all div soup. + Matter of fact is that browser engines and people – nothing less than the ones who you really write code for – won’t ever know about your abstractions. A screen reader won’t know your “button” is actually a button3</a>. (They will definitely get to know the span</code> though, and that won’t help.) + </picture> +xkcd: Tags</a></figcaption></figure> +Also, it’s never been easier to write invalid markup without even realizing it! After React, it seems acceptable to place a button</code> inside an anchor link, and even giant elephants inside span</code>. Has anyone ever thought why they are considered invalid markup in the first place? +Don’t make it hard</h2> +Browsers and assistive technologies are smarter than ever4</a>, indeed, yet they still count on developers to write code they can understand and people can benefit from. By doing so, you make it easy for: + +people, who will be able to navigate around the website, skipping over navigation sections or quickly jumping from one article to another5</a>.</li> + yourself, so you don’t have to reimplement default browser behaviours.</li> +</ol> +Therefore, please: don’t waste features that technologies try to give users, and developers, out of the box. + Remember who you write code for. +^{1 +If I had managed to publish this yesterday, the day would be sunny. I’ve missed the opportunity to make the article seems a little happier. +</div> +}^2 +The button element was first introduced in HTML4. (Source</a>) +</div> + ^3 +What’s wrong with using a non-semantic element as a button? Well, if the button is accessible, nothing really. But doing so demands extra work</a> that nobody is up for, besides that fact that you can’t actually create a button</a>. +</div> + ^4 +Technologies may even process 123-456-7890</code> as a telephone, and allow for automatic dialling of it. See microformat</a> for more information. +</div> + ^5 +Why not, right? After all, article</code>s are for independent pieces of content, e.g., an user-submitted comment or a forum post. (Source</a>) +</div> + Tchau 2017-05-13T16:12:00+00:00 de Viamão, Brasil para Berlim, Alemanha. 🇩🇪 + +– Tu tem que ver o que é pra ti, sabe? Se tu ficar aí, tu provavelmente vai ficar nessa mesma por bastante tempo. É isso que tu quer? + – Não, meu sonho sempre foi morar fora, do país. + – O meu também é. Esse é o meu foco, pra sempre. Eu nunca tirei isso da mente. +</blockquote> + A memória parece distante agora, mas não faz muito tempo que eu tive essa conversa. 30 de Março de 2016. Já faz um pouco mais de um ano. Falávamos de indecisões, insatisfações e mudanças, quando sonhos vieram à tona. + Sonhos. Pessoalmente, penso neles como desejos fixos que habitam a nossa consciência junto a outros desejos, mais efêmeros, e que, assim que você os deixa de lado (nem que seja um pouco), inconvenientemente voltam a te atormentar; lembrar que eles ainda estão lá e não são como os outros desejos. + + +Esse é o meu foco, pra sempre. Eu nunca tirei isso da mente. +</blockquote> + Palavras minhas. Confesso, me assustam. Ou melhor, me assustavam. O que me assusta mais agora é o fato de eu ter lido isto em menos de um ano depois: + +I’m personally very happy to say that after everything we’ve heard and seen, we think you’re a great match for us and would love for you to join our team here in Berlin. +</blockquote> + ([…] Pessoalmente, estou muito feliz de dizer que, depois de tudo que nós ouvimos e vimos, achamos que você tem tudo a ver com a gente e gostaríamos que se juntasse ao nosso time aqui em Berlim!) + O que seria para sempre o meu foco, o desejo que eu descorri por 30 linhas no meu LG R510 em uma carta de maio de 2012, aquilo que eu nunca havia tirado da mente, naquele momento surgia como uma oportunidade. Eu topei. + Foram vários passos antes disso, e eu lembro de estar ansiosa antes de cada um deles. Encontrei pessoas maravilhosas durante o caminho, com um coração tão grande como o meu. Tanto na vida quanto nessa entrevista em particular. + Nas entrevistas, o processo simplesmente fluiu. Penso e gosto de pensar que é o que acontece quando os aspectos técnicos são vistos como meros meios necessários para aquilo que realmente importa: criar. + Desde aquele momento até hoje, o dia do meu voo, o tempo pareceu nunca passar em alguns momentos, e, em outros, passar rápido demais. Mesmo com a percepção confusa do tempo, tenho certeza de que poder enviar a mensagem abaixo é algo que eu não imaginava para tão cedo. + + Just got the call! […] That’s an important moment of my life for sure. I’m just, you know, happy. Thank you for this. + + The call. A ligação se referia a do Consulado Geral da Alemanha de Porto Alegre que recebi no dia 8 de maio, dizendo o que esperei 2 semanas (ou toda a minha vida?) para ouvir. O meu visto estava aprovado. Ali estava, sem dúvidas, um momento importante da minha vida. + Do resto do telefonema, confesso, não lembro muito. Minha maior memória desses instantes foi a de andar com o coração cheio até o centro de Porto Alegre como se fosse a última vez. E foi, pelo menos por um bom tempo. + +Um sonho pode, afinal, terminar de 2 maneiras: sendo abandonado ou realizado. + Meu caso é o segundo, e, sinceramente, não está fácil acreditar. Se você me disser que a partir de hoje eu já não moro mais onde cresci, que meu voo hoje é só de ida, essa informação será processada de forma que ela não faça sentido na minha realidade. Eu não vou acreditar. + Por outro lado, nesse momento da minha vida em que a gratidão transcende o mérito, acredito em várias outras coisas. A principal é que sou o resultado do fenômeno que acontece quando a oportunidade encontra o anseio: alguém, no passado, acreditou em mim; alguém, no presente, acredita em mim. E eu não as deixei decepcionar. + +Hoje estou voando para Berlim, a capital da Alemanha, para fazer o que amo na HelloFresh</a>, que me ajudou em todo o processo. Sou grata por isso, por tudo. + Quanto à realidade, não é que eu não tenha medo. Eu tenho. Eu tive medo em todas as vezes que ousei. Desde o primeiro emprego que fui atrás no Brasil (no tédio do meu Ensino Médio), dos projetos além do meu conhecimento, até o meu primeiro emprego fora do Brasil… eu tive medo em todos eles. + Eu só jamais deixaria o sonho terminar do outro jeito, então eu topei tudo mesmo assim. + Choose Life 🇩🇪 2017-05-12T19:15:00+00:00 Choose life. Choose a job. Choose a career. Choose relocation. Choose giving life a fresh1</a> beginning. Choose an one-way flight ticket. Choose fitting your entire life in a 23 kg suitcase. Choose getting rid of all your crap. Choose a higher Human Development Index. Choose being thousands of kilometers far away. Choose devastating your loved ones. Choose different bureaucracies you still don’t understand. Choose calling another place home. Choose not fitting in (you never did anyway!). Choose saying goodbye to places, food and friends, then choose new places, food, and friends. Choose memories. Choose developing new tastes. Choose being forced to develop social skills. Choose ignorance. Choose mundane and boring activities as exciting adventures. Choose not speaking your mother language. Choose limited self-expression. Choose missing the food from your country, and especially your mum’s. Choose letting part of your heart be elsewhere. Choose adapting 24/7. Choose wondering what the fuck you are doing. And choose getting the answer as soon as you go outside. Choose not understanding jokes from natives. Choose recognising you can do anything, anywhere. Choose not knowing if you should. Choose the bittersweet feeling of moving abroad. Choose to be afraid. Choose your future. Choose life. + But why wouldn’t I want to do a thing like that? + I chose to choose life. And the reasons? There are no reasons. Who needs reasons when you’ve got Berlin?2</a> + ^1 +See HelloFresh</a>, which helped me relocating to Berlin. +</div> + ^2 +The entire essay is inspired by Mark Renton’s “Choose Life” speech from Trainspotting</a>, a movie that makes me think a lot about life choices. +</div> + A Minimal Workspace on macOS 2017-05-04T19:45:57+00:00 Ask me for a screenshot of my desktop and all you get is a wallpaper – if I’m using any. Everything else is hidden, unless actually requested by me. + That’s the way I work on macOS. The minimal way. +</video> +My macOS desktop. This + Spotlight = life. 😎</figcaption></figure> +In my workspace, there are no desktop items, app icons, time clock, battery percentage, transition delays, distracting animations, dashboards or context menus. + Too much information makes it easy for me to get stimulated and then distracted. So I like it minimal. + Recipe for the minimal 👌</h2> +Get rid of everything you can. Hide. Disable. Assume everything is useless, not useful. (I actually use this approach for life.) + You’ll get frustrated sometimes, because there are simple things you want so bad to get rid of but then found out it’s impossible unless you hack things. SRLSY GOTTA LOVE APPLE 😍😍😍 + Well, let’s begin! Follow the steps below and type the commands in a terminal. If you’re not familiar with a terminal, I’m pretty sure it’s possible to find those settings in “System Preferences” as well. + (…But I highly recommend you to open a terminal and start typing around because SRSLY USING A TERMINAL IS LIKE KNOWLEDGE AND POWER 4 UR ENTIRE LIFE!!!!!!!!) +Hide your desktop</h3> +It’s easier to live without than to live with it. Disable it and it won’t be something you have to clean up anymore! +defaults write com.apple.finder CreateDesktop -bool false +</code></pre> +Hide your dock</h3> +It’ll be only shown when you hover it. +defaults write com.apple.dock autohide -bool true +</code></pre> +Other cool things you can do too to keep your dock clean are: +# Minimize windows into their application's icon +defaults write com.apple.dock minimize-to-application -bool true + +# Wipe all (default) app icons from the Dock +defaults write com.apple.dock persistent-apps -array +</code></pre> +Because I initialise apps from Spotlight, I really don’t mind not having any app in my dock. Sometimes I ask myself why do I have a dock at all. 🤔 + And… Launchpad. WHY?????? 😭 + Hide your menu bar</h3> +It’ll be only shown when you hover it. + defaults write NSGlobalDomain _HIHideMenuBar -bool true +</code></pre> +I really like this one, but if you feel it's too radical for you, try hiding only menu bar icons with Vanilla</a> (recommended) or Bartender</a>. + Disable dashboard</h3> +Why does it even exist? 😒 +# Disable Dashboard +defaults write com.apple.dashboard mcx-disabled -bool true + +# Don't show Dashboard as a Space +defaults write com.apple.dock dashboard-in-overlay -bool true +</code></pre> +Disable and/or speed up animations</h3> +Saving some time because I don’t think those really add anything to my user experience on macOS. +# Disable window animations and Get Info animations +defaults write com.apple.finder DisableAllAnimations -bool true + +# Remove the auto-hiding Dock delay +defaults write com.apple.dock autohide-delay -float 0 + +# Remove the animation when hiding/showing the Dock +defaults write com.apple.dock autohide-time-modifier -float 0 + +# Don't animate opening applications from the Dock +defaults write com.apple.dock launchanim -bool false + +# Speed up Mission Control animations +defaults write com.apple.dock expose-animation-duration -float 0.1 +</code></pre> +Finally, restart system stuff: +killall Finder; killall Dock; killall SystemUIServer +</code></pre> +And that’s it! 🎉 Life-changing commands for sure. Now just don’t forget cleaning your actual desk too. +For more on the way I work, my dotfiles</a> are worth-checking! + Sorry for using too many emojis. Just shipped this feature here on my blog and I can't help myself! 😬 + I Travelled to Photographs 2017-04-19T10:13:00+00:00 February was ending. + Usually, such thing would mean regular summer days. However, it wasn’t summer or even a regular day – this was something else. + February 25th was winter. In that cold afternoon, I ended up into a place I’ll never forget: photographs from my phone’s gallery. + +My steps were slow. + Red bricks erected the walls of houses built on top of an equally red-bricked avenue. + The windows of the houses were made of a wood strategically white-colored to match the brick’s white grouts. With such detail, it was pretty easy to forgive the toughness those bricks carried. + Houses ended themselves in grey roofing shingles. The roofs were all hipped. Houses with hip roofs, gotta love them!, I thought to myself. (Imagine the “V” letter upside down on top of a square – that’s a house with a hip roof.) + Showing a winter that was already leaving, dark trees with dry twigs were in contrast against a white sky – the whitest I’d ever seen in my life. Damn! The whole picture looked like a painting, while the white sky worked as the canvas board on which all that was drawn. + I remember walking and trying to get everything I could, until a freezing wind blew abruptly into my face. It was February, though. From where I come, February meant summer, not freezing winds. Why was February that cold? + In an attempt to clear things up, I told myself what I believed that was true: You’re just looking at photographs from your phone’s gallery. There’s no need to get this excited! Ok. So I was home and looking at the “Wallpapers” album I had on my phone. + A moment later, I found myself facing a large and wonderful canal, in which someone was solitary paddling a boat to somewhere. What a view. + Then, self-awareness hit me again: Wait. Isn’t my smartphone in my pocket? How could I be possibly looking at photographs on it? + I immediately started touching my entire body in a desperate hunt for my phone. And there it was. In my fucking coat. It wasn’t really possible for me to see photographs on my phone – that shit was in my pocket all the time. + Besides, why would I be wearing a coat on summer? And, if I was already wearing a coat, how could I be still cold? How inappropriate were my clothes for that weather? Only a person who sensed that winter solely with the eyes would underestimate its coldness like that! + The boat was really leaving through the canal. The view wasn’t photographs. What was all that, then? + I got my phone from my pocket, turned off airplane mode, and opened the Maps app. Come on, where am I? + “Noorder Amstelkanaal”, I read. Wow. + All of a sudden, February 25th was a cold winter in Amsterdam. My very first one. + </picture> +Someone solitary paddling a boat to somewhere in Noorder Amstelkanaal, an Amsterdam's canal.</figcaption></figure> +I guess I travelled to photographs. + Catalysis 2017-04-13T11:27:00+00:00 As a High School student, I remember always finding Chemistry something between the boring and intriguing. Still, it isn’t hard to find myself wondering about the science concepts I’ve learned at that time. + Lately, I’ve been particularly thinking about catalysis. + +In Chemistry, catalysis is the acceleration of a reaction due to the participation of a substance – the “catalyst”. + The way a catalyst induces a reaction to happen faster is intriguing. Curiously, it neither gives the reaction more energy nor change its environmental conditions. Catalysts have an even better strategy: they lower the amount of energy required for the reaction to take place. + </picture> +Uncatalyzed reaction (solid) vs. catalyzed reaction (dashed). The highest point is the energy required for the reaction to happen. </figcaption></figure> +In a catalysed reaction, then, the same product is obtained for less energy. Bringing this concept to our lives is quite thought-provoking. + Sometimes it isn’t possible for us to achieve something because it demands more time or energy than what we currently have. To deal with this, we then try looking for them in our lives – which mostly means depriving yourself of things. + However, matter of fact is that optimising isn’t always about getting rid of things in your life. If we think of catalysis, we can manage it differently. + What if the problem weren’t the lack of energy or time, but that we’re in need of too much of them in order to get things done? Having a catalyst would totally figure it out. Without something that pushes us forward, we’ll always require more energy for the product we want to get. + At this point, you may think your catalyst is your motivation. Motivation is out of our control though – which makes it a goal, not a source. It’s also too ephemeral, and a catalyst mustn’t ever be consumed by an unique reaction, just like in Chemistry. We can’t count on being motivated! + So it goes more like what habitual and practical things in life would give you productivity for less. Is it everyday meditation? A partner by your side? Self-confidence? Inspiring weekends without thinking of work at all? Eating healthy? Going out for a walk every day? + You have to mind what pushes your forward. Catalysts themselves cannot make a reaction happen that wouldn’t happen on its own, but they sure make it occur under less extreme conditions. It’s an improvement when you’re already motivated. + So, what’s your catalyst? + Don't Blame it on React or Redux 2017-03-18T13:49:00+00:00 What most people don’t know when they first get into Redux is that, just like React, Redux itself is meant to be simple. And as seen that simplicity is a goal, both React and Redux won’t and don’t want to tell you how to solve everything. + They won’t tell you how to deal with side effects, or what HTTP request library you should use. That’s completely delegated to the JavaScript ecosystem. + React and Redux alone don’t do much for really complex web applications. + React indirectly delegates state management problems to solutions like Flux. On the other hand, Redux, for instance, delegates dealing with async stuff or even the too-much-boilerplate problem that people complain. + But what motivates React and Redux to be that way? Some reasons I can think of are: + +Both libraries are highly focused on their principles, not the built-in stuff. The efficiency of them is on the why and how, not the what.</li> + They aim to be a great fit for both simple and large applications, so the “plug-in-play” approach is followed. (A framework wouldn’t ever do everything a programmer needs anyway…)</li> +Diversity of solutions. Because React and Redux are more like “plug-in-play”, the “plugins” (tools, libraries, middlewares) will evolve by themselves. For instance: axios</a>, a HTTP request library, will evolve in parallel to Redux itself – which certainly make things move forward faster!</li> +</ul> + +If your application’s state is messy, don’t blame it on React. If you find yourself writing too much boilerplate, don’t blame it on Redux. React and Redux don’t really do much, but this is by design. + React is awesome not just because it makes it possible to turn a large and complex application into simple components. + Redux is awesome not just because it makes it effortless to deal with and share state throughout an application. + They’re also awesome because of their great and diverse ecosystem. So, when you buy into React or Redux, it’s better for you to buy into their ecosystem too. + var that = this? Nah. 2017-03-15T09:00:00+00:00 Tried JavaScript for some minutes? You probably already wrote the following. +var that = this; +</code></pre> +(Or one of its variants, such as var self = this</code>.) + That’s a pretty common pattern when you found yourself in a situation where: + +you have a function nested inside of an object’s method, and</li> + you want to access the object’s properties, but</li> +JavaScript’s this</code> is bound in an unexpected way.</li> +</ol> + +Workarounding unexpected callback scope is one of the main situations where developers write var self = this</code>. + Let’s assume a piece of code with a callback function. +function Requester(data, req) { + this.data = data; + + req.done(function () { + console.log(this.data); // undefined + }); +} +</code></pre> +You’d expect this.data</code> to be the data</code> argument. Yet, JavaScript tells you that it is actually undefined</code>. + So, because Stack Overflow says so, you do the following: +function Requester(data, req) { + this.data = data; + var self = this; // NOOOOOoOooo + + req.done(function () { + console.log(self.data); + }); +} +</code></pre> +And never stops doing it in your life. + Still do it? I’m flattered to tell you that you don’t need that extra variable anymore. +Arrow functions</h2> +Go with arrow functions</a> instead. Besides having a shorter syntax, arrow functions bind to the parent scope by default. + The scope that was firstly intuitive to you will work as expected now. + function Requester(data, req) { + this.data = data; + + req.done(() => { + console.log(this.data); // intuitive as hell! + }); +} +</code></pre> +You can count on them most of the time, but they also have unexpected behaviour in more advanced cases. After all, you're dealing with the `this` keyword. So don't just go around refactoring all anonymous functions into arrow ones and expecting everything to work. +You may also .bind()</code>!</h2> +If for some reason (such as no support for IE</a>) you can’t use them, check JavaScript’s bind</code></a>. It’s not as awesome as arrow functions, but does the job. + function Requester(data, req) { + this.data = data; + + req.done( + function () { + console.log(this.data); + }.bind(this) + ); +} +</code></pre> + Shared Variables Between JavaScript and CSS 2017-01-15T15:00:00+00:00 Because it assures consistency throughout the project and avoids magic numbers</a>, sharing variables between JavaScript and CSS code may help you to keep your project codebase tidy and easier to reason about. + + For this article, when talking about CSS, the word “variable” may mean custom property</a> or custom media query</a>. + + Getting Started</h2> +First, create a object containing your variables and export it. + My JS file containing the object will be called variables.js</code>. +export default { + mainColor: "#000", + secondaryColor: "#fff000", + fullHeight: "100vh", +}; +</code></pre> +No magic is needed to use those variables in your JS files – just import</code> them when you need it. But in order to communicate those variables to your CSS files and use them with var()</code>, some magic is needed. +For this, I will be using cssnext</a>, a PostCSS plugin, and injecting that object into our stylesheets as custom properties. + Webpack example: + import cssNext from "postcss-cssnext"; +import myVars from "./variables"; + +module.exports = { + // Entry, loaders, plugins... + + postcss: () => [ + cssNext({ + features: { + customProperties: { variables: myVars }, + }, + }), + ], +}; +</code></pre> + +Since I’m just using postcss-cssnext</a> API, it’s also possible to do it with the build tool of your choice. Check docs on passing options to cssnext features</a>. + + Getting Real-world with Breakpoints</h2> +Sharing breakpoints between JavaScript and your stylesheets is a great real-world example. + It’s time for variables.js</code> to grow then! +export const properties = { + mainColor: "#000", + secondaryColor: "#fff000", + fullHeight: "100vh", +}; + +export const mediaQueries = { + secondaryColor: "#fff000", + desktop: "(min-width: 1024px)", + tablet: "(min-width: 768px)", + mobile: "(min-width: 320px)", +}; +</code></pre> +Because it’s not possible to create a media query containing a custom property, we need to inject mediaQueries</code> as custom media queries. + Let’s update the previous Webpack example in order to let cssnext to know about both custom media queries and properties. +import cssNext from "postcss-cssnext"; +import { properties, mediaQueries } from "./variables"; + +module.exports = { + // Entry, loaders, plugins... + + postcss: () => [ + cssNext({ + features: { + customProperties: { variables: properties }, + customMedia: { extensions: mediaQueries }, + }, + }), + ], +}; +</code></pre> +Done! Some usage examples for CSS, JS and even React are provided below. + Usage</h3> +CSS Example</h4> +Using custom properties and custom media queries according to settings from variables.js</code> file. +.banner { + background: red; + height: var(--fullHeight); /* Custom property */ + + @media (--desktop) { + /* Custom media query */ + width: 50%; + } +} +</code></pre> +JavaScript example</h4> + +Example below uses enquire.js</a> library. + + import enquire from "enquire.js"; +import { customMedia } from "./variables"; + +enquire + .register(customMedia.tablet, () => { + console.log("Matched tablet resolution"); + }) + .register(customMedia.mobile, () => { + console.log("Matched mobile resolution"); + }); +</code></pre> +React example</h4> +Rendering a component only on desktop resolutions. + +Example below uses react-responsive</a> library. + + import MediaQuery from "react-responsive"; +import { customMedia } from "./variables"; + +function DesktopOnlyComponent() { + /* (min-width: 1024px), according to variables.js */ + + return ( + <MediaQuery query={customMedia.desktop}> + <p>My desktop-only component!</p> + </MediaQuery> + ); +} +</code></pre> +Final Words</h2> +A non-consistent front-end codebase is just messy. + I really use this technique on everyday work, and it’s a cheap way to significantly improve the quality of the front-end codebase. + So, don’t underestimate it! Besides breakpoints, there are infinite possibilities for this, such as project colors, layout dimensions and other shared stuff that can easily get out of hand while working on a large project. + How to Exclude CSS, Images, Anything from Unit Tests 2016-11-19T09:54:29+00:00 +Your app needs all those require</code>, but your unit tests may not. +</div> + When developing web applications, we deal with assets that our JavaScript tests don’t have to be aware of. +If using Webpack, which enables different imports in your JavaScript files, you’ve configured loaders</a> that your test runner probably know nothing about. Therefore, that SVG image in your React component and the import</code>ed CSS will both be parsed like JavaScript in your tests. A lot of confusing errors will be thrown, of course. + So let’s learn to exclude anything your unit tests, from styles (CSS, Sass), images (PNG, SVG), to other specific imports (like SVG images as React components</a>). + Hook your require()</code> calls</h2> +By intercepting require()</code> calls, you can make your testing framework ignore what you want to be ignored the way you want it to be ignored. + It’s also useful in isomorphic setups. +Return an empty module</h3> +It all comes to returning an empty module for unwanted imports. It looks like this: +module.exports = ""; +</code></pre> +Jest</h3> +For Jest, configure moduleNameMapper</a> to return the empty module for specific extensions. Example: + "jest": { + "moduleNameMapper": { + "\\.(css|jpg|png)$": "<rootDir>/empty-module.js" + } +} +</code></pre> +Other testing frameworks</h3> +require-hacker</a> is an option for hooking require()</code> calls. + + You can also use built-in compilers (like moduleNameMapper in Jest or Mocha compilers</a>), or even only import ignore-styles</a> into your testing framework (which is preconfigured). + + I’ll stick to require-hacker and custom configuration because there’s more flexibility. + Get it from npm: + npm install require-hacker --save-dev +</code></pre> +Configure</h4> +Create a JavaScript file and set custom handlers for specific extensions using require-hacker’s hook()</a> method. + Assuming you want to ignore CSS and PNG files, always return an empty module for them: + import requireHacker from "require-hacker"; +requireHacker.hook("png", () => 'module.exports = ""'); +requireHacker.hook("css", () => 'module.exports = ""'); +</code></pre> + +Because you’re smart, you’ll store all extensions in a variable and forEach</code> them, so there’s no need to repeat yourself. Example</a>. + + Import into your test runner</h4> +Let your favourite testing framework know about the require</code> hacking! Some examples, assuming a ignore-utils.js</code> file: +Mocha</h5> +Add to your mocha.opts</a>, or use the --require</code> flag: + mocha --require ./ignore-utils +</code></pre> +ava</h5> +Add to your package.json</code>: +"ava": { + "require": [ + "./ignore-utils" + ] +} +</code></pre> +Now some files will be treated like shit in your JavaScript tests – which is AWESOME! +Bonus: React null component</h2> +You don’t need to load that boring SVG icon of a house to test that critical feature in a React component, right? +Right. In case you’re using svg-inline-loader</a>, which transform your SVG files into React components, you cannot just return an empty module because your test case would be actually expecting a React component. Things will break. Annoying errors will be shown. + So, instead of returning an empty module for SVG files, return an empty React component. Let’s set a custom handler for that! + Configure</h3> + + This example uses require-hacker. For Jest, export a React null component and set it in moduleNameMapper</code>. + +import requireHacker from "require-hacker"; + +const reactNullComponent = ` + require('react').createClass({ + render() { + return null; + } + }) +`; +requireHacker.hook("svg", () => `module.exports = ${reactNullComponent}`); +</code></pre> +Conclusion</h2> +I’ve spent a lot of time figuring out how to make everything work, because: + +At the beginning, it was quite confusing to get what was clearly going on.</li> +There’s a ton of options out there (Webpack null loaders; ignore-styles</a>, which also provide custom handlers; babel-plugin-transform-require-ignore</a>…).</li> + I didn’t want to handle all the ignored extensions the same say.</li> +</ol> +Yeah… Sometimes our JavaScript unit tests just know too much. + A Bit on Random Numbers in JavaScript 2016-11-15T16:50:00+00:00 Math.random()</code> is a JavaScript function that outputs a random number in the range [0, 1)</code> (from 0 up to 1, but doesn’t include 1). It’s the main source of randomness in JavaScript. + Although the output looks random, it’s actually not. +Behind the Scenes</h2> +Math.random()</code> uses a pseudo-random number generator (PRNG). Those algorithms work completely determined by a initial value called “seed”. + +Given a seed, the sequence of random numbers is deterministic. +</blockquote> + Every PRNG requires a seed, which generally is the current system time in milliseconds. Yeah, simple as that. +Speaking of JavaScript language, the PRNG algorithm to deal with the seed is left up to implementors1</a>. The algorithm powering V8’s Math.random()</code> was very poor quality until last year (2015), and implementations between engines were pretty inconsistent. + But the scenario has changed. Currently, JavaScript Engines such as SpiderMonkey, V8, Webkit and Chakra all implements Xorshift128+</a> algorithm2</a>, faster than the previous one. + Secure Randomness</h2> +Although randomness was improved in most JavaScript engines, it isn’t trustworthy as seen that standard PRNGs are highly predictable after a certain period. That’s where Web Crypto API shines! +Web Cryptography API</a> introduces window.crypto.getRandomValues</code>, a cryptographically secure pseudo-random number generator (CSPNG), whose output is impossible or highly improbable to distinguish from a truly random one. + Example</h3> +// Array containing two 32-bit integers +const arr = new Int32Array(2); + +// Override array integers with random values +const random = crypto.getRandomValues(arr); + +for (let i = 0; i < random.length; i++) { + console.log(random[i]); +} +</code></pre> +Of course it comes at a performance cost, so make sure you really need secure random numbers in your program.</a> +Conclusion</h2> +If you need apparent randomness–less and speed, you’d probably better off using Math.random()</code>. If you need high-quality randomness, such as in cryptography applications, hashing or statistics, go for a CSPNG such as window.crypto.getRandomValues</code> instead. +^1 +See ES2015 spec on Math.random()</code></a>. +</div> + ^2 +Sources: SpiderMonkey</a>, V8</a>, Webkit</a>, Chakra</a>. +</div> + Horizontal and Vertical Align Anything with CSS 2016-11-06T19:10:01+00:00 Using translate()</code> is one of the easiest ways^[Flexbox also provides a great solution. See Solved by Flexbox: Vertical Centering</a>] to instantly horizontal and vertical align any element with CSS without knowing its dimensions. + Vertical Align</h2> +You probably know the “vertical align with just 3 lines of CSS</a>” trick, which uses translateY()</code>. + .my-element { + position: absolute; + top: 50%; + transform: translateY(-50%); +} +</code></pre> +Horizontal Align</h2> +But did you know it’s also possible to use translate()</code> to horizontal align elements? +.my-element { + position: absolute; + left: 50%; + transform: translateX(-50%); +} +</code></pre> +Vertical and Horizontal Align</h2> + Mixing both, we can horizontal and vertical align anything! +.my-element { + position: absolute; + left: 50%; + top: 50%; + transform: translateX(-50%) translateY(-50%); +} +</code></pre> + +See JSBin</a>. + + A Better ES2015+ and JSX Workflow in VS Code 2016-10-30T00:00:00+00:00 Lately I’ve been trying VS Code</a>, a code editor based on Electron</a>. Since then, it really surprised me and it’s been a nice coding experience. + But…</h2> +By default, JS syntax highlighting and ES2015+ and JSX support don’t work as expected. + I’ve tried to workaround it by using: + +Atom grammar</a>. JSX support was pretty bad.</li> + A development branch of VS Code colorization</a>, which is delivered as an extension. Finally got JSX to work properly, but syntax highlighting was still missing something.</li> +</ol> +So, no success. + Improving your VS Code workflow</h2> +After much trial and error, I came up with a better JS workflow in VS Code. +1. Fix JS syntax highlighting</h3> +Install the Sublime Babel extension</a> and make sure you’re using one of the suggested color themes. (I like Charcoal Oceanic Next</a>!) + 2. Use “JavaScript React” in .js files</h3> +VS Code only uses “JavaScript React” syntax in .jsx</code> files. Add the following to your User (or Workspace) Settings: +"files.associations": { + "*.js": "javascriptreact" +} +</code></pre> +3. Enable Emmet for JSX</h3> +(That’s a plus!) + VS Code uses Emmet by default, but doesn’t enable it for .jsx</code> files. Add the following to your User Settings: +"emmet.syntaxProfiles": { + "javascript": "jsx" +} +</code></pre> +Let’s improve VS Code!</h2> +There has been improvements for JS grammar</a> already, but it’s still not perfect. + Fortunately, VS Code is an open source project</a> and can be improved by developers like us! Let’s not leave it like this. Give useful feedback and help! + Happy coding! + I'm Tired of Beautiful-Looking User Interfaces 2016-10-23T12:50:35+00:00 +What if the user interface is more beautiful-looking than usable, understandable, and intuitive? +</div> + The visual aspects of an user interface play an essential role in organising information. Once you’ve got the resources, however, that turns out to be the easiest part of an Interface Design process. + Sure we like things that look nice, but looking nice doesn’t compensate a bad product design. Visual communication should not compensate flaws. + If you spend most of the time looking for visual inspiration rather than conducting research, doing usability tests, and studying metrics such as business goals and conversion rates, you will probably come up with a interface that only looks beautiful. + And I’m tired of beautiful-looking interfaces. + Encadeamento de Métodos em JavaScript 2016-08-06T16:11:32+00:00 Popular em diversas bibliotecas JavaScript, o encadeamento de métodos (“method chaining”) é uma técnica usada para invocar diversos métodos em um mesmo objeto. + Com o objetivo de melhorar a legibilidade do código, a técnica é vastamente utilizada na API da jQuery, o que certamente influenciou na popularidade da biblioteca. + Se você já utilizou jQuery, o estilo do código abaixo pode ser familiar: + $("#my-element") + .css("background", "purple") + .height(100) + .animate({ height: 250 }) + .find("input") + .fadeIn(200) + .val("") + .end(); +</code></pre> + + No exemplo acima, uma única declaração faz várias coisas. No entanto, uma boa prática com method chaining é fazer somente uma ação por declaração. ;-) + + Perceba que vários métodos são invocados no objeto $('#my-element')</code>, sem a necessidade de repetí-lo. Já sem Method Chaining, é necessário fazer a referência diversas vezes: + const myElement = $("#my-element"); +myElement.css("background", "purple"); +myElement.height(100); +myElement.fadeIn(200); +</code></pre> +Exemplo</h2> +Vamos criar um contador Counter</code>: + class Counter { + constructor() { + this.value = 0; + } + + increase() { + this.value += 1; + } + + decrease() { + this.value -= 1; + } + + log() { + console.log(this.value); + } +} +</code></pre> +Agora, vamos instanciar um contador e usar seus métodos: + const counter = new Counter(); +counter.increase(); +counter.log(); // => 1 +counter.decrease(); +counter.log(); // => 0 +</code></pre> +Perceba que é necessário fazer várias declarações para interagir com a instância, o que prejudica a legibilidade do código. + E se tentarmos usar Method Chaining… + new Counter().increase().log(); +// > TypeError: Cannot read property 'log' of undefined +</code></pre> +Perceba que log()</code> está sendo executado em new Counter().increase()</code>, que, por sua vez, está retornando undefined</code>. Portanto, ainda não é possível interagir com Counter</code> dessa forma. + Como Encadear Métodos</h2> +Para evitar a repetição do objeto, é necessário que seus métodos retornem o próprio objeto. + Veja este exemplo com Promises: + getJSON("users.json") + .then(JSON.parse) + .then((response) => console.log("Olha o JSON!", response)) + .catch((error) => console.log("Falhou!", error)); +</code></pre> +Isso só é possível pois os métodos then()</code> and catch()</code> sempre retornam outras promises. Assim, podemos dizer que as Promises são fluent APIs, tal como a jQuery. + Quem Lembra do this</code>?</h3> +Para os métodos serem encadeados, será necessário retornar o contexto (this</code>) em cada método. + +Em JavaScript, this</code> sempre se refere ao contexto de execução de função. +</blockquote> + No caso de um método, que é uma função de um objeto, refere-se ao próprio objeto. + Exemplo com Method Chaining Pattern</h4> +Para implementar o encadeamento de métodos na classe Counter</code>, apenas retornamos seu contexto a cada método: + class Counter { + constructor() { + this.value = 0; + } + increase() { + this.value += 1; + return this; // Aqui! + } + decrease() { + this.value -= 1; + return this; // Aqui! + } + log() { + console.log(this.value); + return this; // E aqui! + } +} +</code></pre> +Agora, ao executar new Counter().increase()</code>, o retorno já não será mais undefined</code>. + …E, portanto, é possível fazer method chaining! + new Counter() + .increase() + .log() // => 1 + .decrease() + .log(); // => 0 +</code></pre> +Conclusão</h2> +No universo de APIs orientadas a objetos, o encadeamento de métodos é uma técnica incrível se o seu objetivo é tornar o código mais expressivo e fluente. + No geral, fluent APIs são sim interessantes de se entender e implementar, e você pode ter certeza disso analisando o primeiro exemplo com jQuery do início deste artigo. É fantástico! Mas é importante entender que o encadeamento de métodos nem sempre tornará as coisas mais fáceis (debugar, por exemplo, se torna mais difícil), e, portanto, a maneira aparentemente “mágica” com que elas funcionam não deve ser sempre levada em consideração. + SVG Images as React Components with Webpack 2016-08-02T22:00:00+00:00 If you’ve ever tried to load inline SVG (using svg-inline-loader</a>) into React, you know it seriously hurts people’s eyes. + import React from "react"; +import IconRemove from "./icons/remove.svg"; +const RemoveButton = () => ( + <button> + <div dangerouslySetInnerHTML={{ __html: IconRemove }} /> + <span>Remove</span> + </button> +); +</code></pre> +So what if it looked like this instead? +import React from "react"; +import IconRemove from "./icons/remove.svg"; +const RemoveButton = () => ( + <button> + <IconRemove /> + <span>Remove</span> + </button> +); +</code></pre> +Much better, don’t you think? +That’s what svg-react-loader</a> does. It process your SVG file and returns a React component, which is compiled with Babel (more on this below). + Using the Loader</h2> +npm install svg-react-loader --save-dev +</code></pre> + +Refer to Webpack docs</a> for more information on loaders usage. Also, make sure you have installed svg-react-loader’s dependencies</a>. + + 1. In Module Request</h3> +The simplest method, although the configuration convention is preferred. Using svg-react-loader and babel-loader</a>, import your icon just like: + import IconRemove from "babel!svg-react!./icons/remove.svg"; +</code></pre> +2. In Webpack Config File (Recommended)</h3> +Add in your Webpack configuration file’s loaders</code> array. + { + test: /\.svg$/, + loader: 'babel!svg-react' +} +</code></pre> +Import your icon just like: + import IconRemove from "./icons/remove.svg"; +</code></pre> +Usage Examples</h2> +Loader in module request method (1): + import React from "react"; +import IconRemove from "babel!svg-react!./icons/remove.svg"; +const RemoveButton = () => ( + <button> + <IconRemove /> + <span>Remove</span> + </button> +); +</code></pre> +Loader in Webpack config file method (2): + import React from "react"; +import IconRemove from "./icons/remove.svg"; +const RemoveButton = () => ( + <button> + <IconRemove /> + <span>Remove</span> + </button> +); +</code></pre> +A Note on SVG Loaders</h2> +Sometimes, we don’t want all of our SVG files to be loaded as React components. If you use a SVG in a img</code> element, for example, it may lead to conflicts. Fortunately, you can avoid them by being more specific in test</code> regular expression: + { + test: /\.inline.svg$/, + loader: 'babel!svg-react' +}, +{ + test: /\.jpe?g$|\.gif$|\.png$|^(?!.*\.inline\.svg$).*\.svg$/, + loader: 'url' +} +</code></pre> +Now, only SVG files ending with .inline.svg</code> will be loaded as React components. You’re good to go! + A Cascata das Variáveis do CSS 2016-05-30T22:00:00+00:00 Suporte</a> | Especificação</a> + Muito embora todos os seres humanos do Planeta Terra tenham odiado sua sintaxe, as variáveis finalmente chegaram ao CSS – e elas são mais poderosas do que você imagina! + Motivação</h2> +O desenvolvimento de grandes aplicações web implica inevitavelmente em grandes folhas de estilo, que devem ser organizadas de forma que facilite a manutenção. Muitos valores definidos para propriedades são repetidos, quando poderiam ser reutilizados e padronizados, de forma compartilhada, pela folha de estilo. + Nesse contexto, surgem as variáveis no CSS, também chamadas de Custom Properties – pois, tecnicamente, é isso que elas são. +Definição</h2> +As Custom Properties são propriedades CSS customizadas (ou seja, você configura o seu valor) iniciadas com --</code>, de nome case-sensitive, e que são utilizadas no documento através da função var()</code>. Por serem propriedades, é importante compreender que seu comportamento é idêntico ao de uma propriedade qualquer do CSS (guarde essa informação!). +Exemplo</h3> +:root { + --colorPrimary: purple; +} + +a { + color: var(--colorPrimary); +} +</code></pre> +(Eu não conheço ninguém que gosta da ideia esplêndida do --</code>. Mas elas não vão deixar de iniciar com --</code> se você reclamar. Inclusive, isso já foi discutido o suficiente</a>.) + A função var()</code></h2> +Quem viabiliza o uso de Custom Properties? Ela: +var( <custom-property-name> [, <declaration-value> ]? ) +</code></pre> +O primeiro parâmetro é o nome da propriedade, e o segundo, opcional, é o valor a ser usado como fallback caso o primeiro argumento seja inválido (por exemplo: uma variável com 20px</code> sendo usada como valor de um background</code>, ou variável inexistente). +Escopo</h2> +Cascata, especificidade, herança… Esses conceitos são muito importantes para entender o poder das variáveis do CSS – e do CSS no geral, eu diria. + Aqui, uma das informações mais importantes deste artigo: As Custom Properties seguem regras de cascata tal como qualquer outra propriedade do CSS. + Por isso, quando quisermos que a variável esteja disponível “globalmente” (para todos os seletores), a declaramos no seletor :root</code>, que é o próprio documento HTML. Isso acontece pois o efeito cascata do CSS permite que todos seus descendentes herdem a propriedade. Legal, né? + A propriedade customizada, tal como qualquer outra propriedade, pode ser sobreescrita através de seletores. Seu valor será definido de acordo com a especifidade deles. + + A implementação de Custom Properties do CSSNext não segue regras de cascata. Apenas variáveis declaradas no :root</code> são válidas. :-( + +Exemplo</h3> +:root { + --bgColor: indianred; +} + +div { + --bgColor: darkseagreen; +} + +#wow { + --bgColor: darkcyan; +} + +* { + background-color: var(--bgColor); +} +</code></pre> +Nesse caso: + +Todos os elementos são vermelhos.</li> + Exceto elementos div</code> e seus filhos, que seriam verdes.</li> +Exceto o elemento com id wow</code> e seus filhos, que seriam ciano.</li> +</ul> +As últimas versões do Firefox e Chrome já implementaram as variáveis nativas do CSS. Se estiver utilizando algum desses navegadores, o exemplo abaixo ilustrará o funcionamento do CSS acima. +JS Bin on jsbin.com</a>

Diéssica Gurskas

We Misunderstand Learning

Fetch a npm package on GitHub without npm install

The Bitter Reality of Ebooks and the Kindle Model

Keep reading</h2> +…on how despite massive technical effort and corporate interest, DRM is a flawed security model.</p> +

Long Time No See

What I've Learned by Simply Journaling

What I’ve Learned</h2> +I'd not assume these stem necessarily from the way I set myself up. Audio or video recordings, traditional diary, and other journal formats are worth exploring and might help just as well.</p> +

References</h2> + +Learn Bullet Journal</a></li> +</ul> +

How to Spy on a React Prop with Jest

Setup for Audio Interface with Guitar Rig 5 on macOS Mojave

OMG Climate: Reflecting Together on the Climate Catastrophe

Awareness in developing countries</h2> +The rich, the poor and the Earth.</p> +

Action points</h3> + +everyone to assure inclusivity, cooperation and engagement across boundaries, first and foremost</strong>.</li> +

I've Sensory-Deprived Myself In a Tank

How I Lock My Bike in Berlin

Working Better with Git for a Clear History

Squash commits when you can</h3> +You need to fix a typo, update a test, or include anything else that should have actually been part of a commit previously introduced. You can create a new commit and later squash it to the initial one with rebase.</p> +

Stash to save your work in progress</h3> +You want to check or change other branch’s files, but don’t want to commit unfinished work either. You can stash your work in progress</strong> (“WIP”):</p> +

Computer and Human Languages

React and Form Management: Is Redux Form Worth It?

Persistence</h3> +Since the state is already in the Redux store, Redux Form is easily pluggable with tools from the ecosystem.</p> +

T. T. T.

Writing Mode in VS Code

My Hacking Adventure in Lithuania

Creativity

Dental Health and Habits

Expressive JavaScript Conditionals (for Humans)

5. Check for any condition</h3> +What if we’ve got crazy and we’re fine considering something a banana when it’s either yellow, Brazilian or sweet?</p> +

Check for all conditions, revisited</h4> +Imagine if we had a lot of conditions for isBanana</code>. We could use &&</code> or even all</code>.</p> +

UI Components that Abstract Mistakes

Tchau

Choose Life 🇩🇪

A Minimal Workspace on macOS

Hide your dock</h3> +It’ll be only shown when you hover it.</p> +

Disable and/or speed up animations</h3> +Saving some time because I don’t think those really add anything to my user experience on macOS.</p> +

I Travelled to Photographs

Catalysis

Don't Blame it on React or Redux

var that = this? Nah.

Shared Variables Between JavaScript and CSS

Usage</h3> +

CSS Example</h4> +Using custom properties and custom media queries according to settings from variables.js</code> file.</p> +

JavaScript example</h4> + +

React example</h4> +Rendering a component only on desktop resolutions.</p> + +

How to Exclude CSS, Images, Anything from Unit Tests

Mocha</h5> +Add to your mocha.opts</a>, or use the --require</code> flag:</p> +mocha</span> --require</span> ./ignore-utils +</span></code></pre> +ava</h5> +Add to your package.json</code>:</p> +

ava</h5> +Add to your package.json</code>:</p> +

Bonus: React null component</h2> +You don’t need to load that boring SVG icon of a house to test that critical feature in a React component, right?</p> +

References</h2> +
+
Learn Bullet Journal</a></li> +</ul> +