When other website owners realize how much traffic you send them that is good for you. Maybe they want to sponsor that newsletter if it’s driving a lot of business.
My advice is to check LinkedIn for listings but don’t apply that way. “Easy Apply” lowers application friction so effectively that every posting gets ~1000 applicants of which few are actually qualified. I don’t think I ever heard back on a LinkedIn-submitted application even for jobs where I had rare and directly applicable experience.
In the last six months I’ve been hired once after applying (on the website of the company itself) to s job posting I first saw on LinkedIn. I was poached shortly after via inbound from recruiter on LinkedIn
In Canada, it seems like there’s a large and growing number of remote jobs available at US software firms through employer-of-record startups like Deel and Remote. Canadian software engineers are surprisingly cheap, relatively speaking, especially when you hire outside the Toronto area.
Economic realities mean there’s quite a bit of downward pressure on CAD right now, so this is likely to continue to be a good deal on both sides for quite a while.
I’m still getting approached by recruiters for Canadian-based remote roles like it’s 2021.
I’ve used Placemark for well over a year to build custom map-based graphics for torontoverse.com. There are a lot of web apps in this space now, and always QGIS, but I personally felt Placemark struck the right balance between simplicity and power.
I’d love to see you elaborate on this. Anecdotally, my experience was the exact opposite. Is there some documentation making this point?
In the course of optimizing I came to know the various JVM GC algos (concurrent mark/sweep, parallel old, etc) by the corresponding memory graph alone. I never, ever had to debug similar latency in the Go stack.
Teasing this apart I see a few things: a) logging, b) modules rollout and c) missing frameworks.
I’ve never had a logging issue in large systems. Explicit error return (as you know, on every function) allows you to log in your code, not lean on only libraries that support your interface.
Modules rollout was part of growing up. But, you won’t get Go 1->2 upgrade issues as we have 100% backward compatibility on version upgrades. Moving to the latest version of Go is trivial and simply unlocks new features.
Too many allocations for Go is going to be too many allocations for JVM too. This seems like an problem isolated to that team.
I’ve done Go at both a three engineer startup and at Google and I can’t help but notice none of these are really the type of problem that crop up later.
Curious to understand what you are suggesting here. What’s a better story for polymorphism than duck typing? What would (better?) null-safety look like in Go?
I’ve got to disagree with this strongly. I built and operated the same large system in both languages (acquisition forced me to rewrite) and both the dev and operating cost of the JVM was much higher.
Go is a high velocity language. Code reviews on language/style issues are non existent, it’s GC is blazing fast (not our experience with JVM) and it’s really easy to read. I’ve watched many new engineers ramp up on both systems, as both operated side by side for a while, Go was inevitably faster for engineers.
I write a lot of Go and I can’t tell you how much this warms my heart.
Compatibility probably isn’t much fun for the language team, always having to keep one foot firmly in the “distant” past. But for those of us that have to maintain large Go systems it’s such a gift.
He usually goes by JM Fortier on YouTube and I think he’s great. He’s a real inspiration to me, for sure. He’s very open and has a lot of stuff up there on various channels about the development of his market garden.
Just to be pedantic, I’ll point out that’s literally “transparent” matter and we use the term “dark” which is really more appropriate for something that absorbs EM radiation because it also implies the mystery of the holes in our knowledge. English is great.
Hiawatha is more than just a leader he’s essentially a religious figure to the Haudenosaunee who historically reside in roughly the area around Lake Ontario.
It is definitely in bad taste to take a meaningful symbol from an existing marginalized culture and use it to brand your open source project because you think it sounds cool. But, this is something that was not widely recognized as bad until very recently, especially outside North America, and obviously this already happened a lot in the past so I don’t think it reflects badly on the authors or contributors at this point. That said the name should change and, at bare minimum, that cartoon has to go.
It’s a great idea, though, for us all to learn the real story of Hiawatha, the Great Peacemaker, Jigonsaseh, Tadodaho and the origins of the Five (now Six) Nations. It’s not an exaggeration to say that it helped inspire the structure of the early USA. It’s also a refreshing alternative take on power and leadership from what we are usually shown in the West. One of the world’s great cultural treasures, I really think.
If you store protos in your Redis keys (like most people using “NoSQL” for data storage), this comment doesn’t have much punch. Pretty sure we all can think of some pretty high profile examples of NoSQL + structured data working very very well at scale.
The Timeless Way of Building describes a philosophy, not just of building practice but really of how to live a good, fulfilling life. A Pattern Language is an set of examples of how to shape specific parts of your community and home to implement that philosophy.
Following the patterns without understanding the philosophy makes no sense to me because it’s a very opinionated and, in the modern world, quite radical. What if you don’t agree with it? I think many don’t. At least, you want to be able to read them critically.
Reading A Pattern Language without reading The Timeless Way of Building makes no sense at all. We do it, I think, because many technologists stumble on A Pattern Language through its relationship to Gang of Four and other “pattern” approaches. The book I always return to, more and more as I get older, is The Timeless Way of Building.