I've been a fan and user of David Seah's calendar for 3 years now.
https://davidseah.com/node/compact-calendar/
I keep a pdf and screenshot version on my desktop and phone. For date ranges, I use the excel version.
363 karma · joined February 24, 2016
https://davidseah.com/node/compact-calendar/
I keep a pdf and screenshot version on my desktop and phone. For date ranges, I use the excel version.
Problem was there wasn't a good answer to "How much redis does your team need to know to put it in production".
We thought we knew it well enough, we thought we knew what we were getting into, and we thought so many others are using it for this, we should be good. That is makes a difference, clearly.
There were many problems but at the core of it, this was us having redis write huge amounts of data to disk very frequently causing this.
We could not reduce the frequency (product would not allow) and we couldn't find a way to make the writes reliably fast.
I like to believe there exists a possible way of handling this, but point being, our team had no time to find out, how redis works internally and have confidence that the new way won't bring up new surprises.
Case in point our team went with Redis, just the default, use it blindly without fully understanding our requirements and how redis helps scale.
2 years later we spent 2 sprints, holding back the release trying to understand RDF vs AOF, and why we're seeing massive spikes in consumption and performance triggering pod eviction, running comparison tests to prove which works better and explaining why, running qa tests (regression, performance, load), introducing postgres for queuing, redoing our code to bypass the sync mechanism between how data flows between redis and postgres, updating dependenciies, migrating existing customer data (various on site locations), explaining this to team members, managers and their managers, installation technicians, support engineers and presenting it at engineering townhalls as a case of bad decisions.
Not worth it.
Spending time and money looking for lighter materials even when the bridge is designed to support a lot more weight than traditional time tested materials. Justification : "Maybe cars will get heavier, and bigger saving 3 pounds is a good pursuit"
Nothing beats the fluidity, ubiquity and the sheer aesthetic quality of pen on paper. Excellent for diagrams and notes as I am discussing something on a call, or explaining things (mostly yo myself) consuming information dense video or audio content.
But I don't always have my notebook on me, and I tend to loose bits of paper easily. So to capture thoughts, I use "email thyself" on my phone.
Every once a few weeks, I clear out my inbox. Most notes go to junk. Some get cross referenced. Fewer still become actual files in my git repo.
My git repo is just a versioned bunch of files with upto 2 levels of hierarchy.
This works amazingly well, for capturing information. no lock-ins, no fear of losing content, frequently gets cleaned up and cross referenced with version history (which I dont mind losing as I have dates in the text files themselves).
What I haven't figured out (yet) is a sustainable way to regularly go back to the content I've collected to keep them rolling through my memory without it being an overwhelming amount of work.
Refreshing things regularly is the best, most effective way to find patterns and make better connections. Haven't broken that code yet.
I don't love eclipse, not a person to get too attached to an IDE, but it is an incredible piece of open source software. It works.
Also too much effort in rewiring keyboard shortcuts that have made their way to my muscle memory. So eclipse it is.
You are right, this IS madness.
Good quote!
I always feel philosophy is the abode for people who couldn't get sucked in by religion.
If you don't, and play cautiously, your competition will eat your market and starve you. You still eat the dust.
I just don't get it.
I imagine, for a manager to get rid of someone on performance grounds needs heck a lot more work and time than getting on the company wide blanket firing bandwagon.
"We hate to let you go but we have no options in these challenging times" gets less opposition from employees and more legal stance over any performance related reason.
Sad.
Hah, had a good laugh out of this. Thanks for sharing.
> Drawabox's goal is to provide beginners with a strong foundation, and to equip them with the things a lot of other courses and tutorials tend to take for granted.
> It is not going to make you a professional on its own, but it will teach you how to practice, how to use the resources available to you on the internet, and equip you with the tools and skills you need to take advantage of them
100% agree with this. I have settled on a very lightly (headers and lists) formatted markdown file. I like how I can just click on bookmarked link from the rendered HTML file to load in the browser (vs. copy paste from text files).
I did write a script to parse this file to mark broken (non 200 response code) links but forgot about it till now. Time to fire it up again.
The problem with being a small shop selling POS products is finding customers at the right time. It is very sales intensive process. You have to reach them at the right time, once a restaurant is invested in a POS, it is almost impossible to convince them to switch. They choose to just live with whatever choice they made and focus on other things that matter. So now, as a developer, you need to give them a good reason to switch.
Money is a good one. So now you are in a price race to the bottom; never a good place to be as a small shop.
Another common ask is integration. They want to try out the product before committing but they can't afford to train folks to use two products at the same time. So now you need to come up with an integration strategy without even having a clear API/structure to work with.
It's a nightmare. Unless you have customers ready to commit which to me seems impossible in the retail business without already knowing people on the inside.
With NodeJs, its a semi-annual affair to move and migrate or face unexpected broken 'npm install' commands. Fix the tooling, fix CI/CD, ignore warnings, application upgrades now require installing newer Node versions, no backward compatibility guarantees of any kind. Its a fool's errand.
I hate to see Java go this route. I don't think this will end well for the Java ecosystem.
A half yearly summary of distilled main themes, decisions and learnings has been crucial for me to continue my journalling process.
When I want to know what I was doing late 2017, I go through my summary. Any detail I want to re-visit is available in my running log.
* Brevity is important. With journalling, it is very tempting to go off on a rant. Feels good at the time but its usefulness declines rapidly with time. Short notes that encompass your state of mind or emotions or feelings with some context and timestamps go up in personal value with passage of time. I keep details and rants in my separate running log files.
* Summarize regularly. Every once a few months when you have down time, summarize your notes and make observations. My favorite bit is to find an old note with a sidenote/annotation and see how I look at the same things differently or still have the same mindset.
* Use timestamps. I have settled for a yyyymmdd-topic-title.txt for filenames. Contents in each file are stamped [yyyy-mm-dd] with optional time of the day. I have under 50 such files and they seem to encompass all facets of my life that I journal.
* Use plain text. Everything else will go away. I now use notational velocity/nvAlt with simplenotes sync for my topic wise notes (I also check in these files into a separate git repo folder for backup). I keep Deep insights and running lists in that git repo's wiki. I've recently also started keeping and checking in monthly yyyy-MMM.md files for a running log of thoughts. Helps maintaining a timeline to find recurring patterns. If some topic becomes worthy enough for sharing via a blog post, it gets its own markdown file that I can edit and customize for publishing.
* Reduce friction. I think this was the big one to overcome. By the time I would get to writing, I'd lose perspective or details to write. I now use a throwaway app (google keep) to write down my reaction, emotions or interesting facts as close to encountering them as possible. Then I can expand on them or discard them when I get time.
As a dev, what D3 did right for me is kept the code stable, provided clear sample code for most use-cases, the internet (thanks folks) made lots of runnable examples available via blocks and jsfiddle, maintained precise documentation (even for older versions in github as markdown files) and has almost no external dependencies (so my local .js+.html files from 3 years ago still work without needing any broken npm install or jspm install)
Moving from v3 to v4 was not as painful as I thought it would be.
Once I got over the core concepts of selections and enter/update/exit cycles it has been a breeze and a pleasure to work with.
Thanks Mike and everyone else who's made reasonable and sensible choices for D3 !