Mailinator.com has a free version .. just use any inbox @mailinator.com and voila!
1,899 karma · joined January 24, 2008
The x230 onward is also extremely good.
The trick for me is key travel. I bought a new Thinkpad that had 1.3mm of travel and instantly hated it. 1.5mm feels so so much better (not to mention 1.8mm). No new thinkpads have above 1.3mm I believe (in the pursuit of thinness).
A long time ago, I got interested in computers to make games but immediately veered into other kinds of software. No worries - I always planned that once I was "done" in the application/startup space, I'd head back and make those games.
Sadly - I waited too long. Like music, books, or photography - the supply-side is so inundated with content that the market is more about marketing than creation or merit. Mind you, never did I expect or even care if I made money. That was never the goal. But now I realize just to get some people to play my game would be a huge undertaking requiring tons of luck - just to rise above the noise. That was the deal breaker - I don't care about making money - but I do care about eventual players, at least if something will take months or years* to create. I wanted to make games, not do marketing.
The bright side is there's no shortage of fun games to play. I'll stay on the player side of the equation!
*Wouldn't be surprised if something like ChatGPT allows games to be made in days in the semi-near future. If so, I just might make games anyway - still not for money, and now not for players - but just to finally let those ideas out of my head.
Just enter any inbox you want at the top of the homepage.
Bob called me after Zuck's announcement that the system hit a peak of (wait for it), 5 transactions per second. And that for only a very short time. The system was mostly only loaded with a transaction every few seconds (or maybe even minutes)
The Ruby version would have been fine. Heck, we probably could have just printed the transactions to some screen and have someone write them down at that speed.
We did have a good laugh though.
In 2010, Zuck gave a lot of money to NJ schools. For reasons completely unknown to me, Bob, who was at Square at the time, was given the task of writing the code to accept the donations that would be given from the public alongside Zuck's gift. For reasons also completely unknown to me, Bob called me and asked me to help write the code. We had something like 3 days. I was working at my own startup at the time but was excited to go work on this one-off with Bob.
We had worked together at Google and spent a lot of time in the Java community thereafter. We were both Java geeks at the time, but I was confused why he couldn't find anyone at Square.
In any case - I went to Square each day for 3(?) days. I remember that we didn't need to process the transactions (thank goodness), but we just needed to validate and log them which made the problem much much easier. Bob insisted we write each transaction to 3 different machines for redundancy. He also insisted we used fsync which ensured the disk writes actually happened and didn't just get left in an output buffer. He was absolutely right, but I remember being saddened how much slower it made our system.
We finished the system with time to spare. Unbeknownst to me (and maybe Bob I guess) another team at Square also implemented the system in Ruby in competition with us. I recall them being rather "anti-Java" at the time.
In any case, we then benchmarked both systems and unsurprisingly, the Java version was many times faster than the Ruby version (in transactions stored per second). Of course, apart from fsync, this was also not just Java code - it was CrazyBob's Java code which wasted nothing. I really had a blast working on that project with him.
I now realize I really don't know so many finer points of why many of these decisions were made. If any early Square folks were there for this, I'd be interested in what you remember.
The answer is that Thinkpad has slowly evolved their keyboards to be slimmer. Reducing the travel on the keys with each step.
Some of the new ones are down to 1.3mm of travel. I realize this is a personal preference, but I noticeably make more errors under anything less than 1.8mm of travel.
Hence, I got rid of the Carbon and bought a Thinkpad T14 Gen 2 which is pretty much the latest model with 1.8mm. The Gen 3 was available, but they trimmed it down to 1.5mm.
I realize this is a pretty picky hill to die on, but I can't express how significant it is for the reliable use of keyboard for me. I'll be buying T14 Gen 2's until I die it seems from here on out. Everything else about the laptop is just fine. Runs any linux I throw at it, 4k screen if desired, all the upgrade-ability I might want.
(If you get lucky, you can even find one with a proper Ethernet port. Some come without because apparently during the chip-shortage, they removed that feature)
For such a closed track (known route to the centimeter, guaranteed no obstacles, etc) - a Self-Driving version of this could do it a good deal faster.
The time I spent getting a Ph.D. was one of the best times of my life. Not just the work, but the environment, the other people in the same situation, and the personal growth. I pursued it because 1) I really did love learning about Computers, and 2) I just loved the University environment. Every time I "graduated" I just signed up again for the next degree.
I never thought much about "using it" after I got it. I think it got me a higher starting title at a company or two and impressed a few (probably easily impressed) people along the way. I think the most measurable* impact however was listing it on my dating profile.
Again - it was a journey worth taking without much thought of the destination.
*Note, I said "measurable", not "good" or "bad"
Not sure you meant it, but this is an inadvertent attestation for "leetcode". As in, it's not about the leetcode, it's about the type of person that masters the leetcode.
It might have actually been worse, because there was a strong penchant for naming products starting with a "J" to indicate the fact (i.e. JNotepad, JDatabase, etc).
It might actually be a good marketing technique to get other Rust aficionados to try your product. But otherwise, there isn't any real value now that "write once, run anywhere" doesn't just belong to Java anymore.
I still attest though - The 5M connections in this example is still a red herring.
Can we get to 6M? Can we get to 10M? Is that a question for Loom or Java's asynchronous IO system? No - it's a question for the operating system.
Loom and Java NIO can handle probably a billion connections as programmed. Java Threads cannot - although that too is a broken statement. "Linux Threads cannot" is the real statement. You can't have that many for resource reasons. Java Threads are just a thin abstraction on top of that.
Linux out of the box can't do 5M connections (last I checked). It takes Linux tuning artistry to get it there.
Don't get me wrong - I think Loom is cool. It's attempted to do the same thing as Async/Await tried - just better. But it is most definitely not the only way to achieve 5MM connections with Java or anything else. Possibly however, it's the most friendly and intuitive way to do it.
*We typically vilify Java Threads for the Ram they consume. Something like 1M per thread or something (tunable). Loom must still use "some" ram per connection although surely far far less (and of course Linux must use some amount of kernel ram per connection too).
That's a very cool and a noble pursuit. But the title of this article might as well have been "5M persistent connections with Linux" because that's where the magic 5M connections happen.
I could also attempt 5M connections at the Java level using Netty and asynchronous IO - no threads or Loom. Again, it'd take more Linux configuration than anything else. If that configuration did happen though now you can also do it in C# async/await, javascript, I'm sure Erlang and anything else that does Asynchronous I/O whether it's masked by something like Loom/Async/Await or not.
Relevant Escapist video about out-of-control rampant copying in Mobile Gaming: https://www.youtube.com/watch?v=Q30qZSEnI9Q
The biggest thing they're bringing to the table is the (supposed and impending) funding. The idea itself is nearly worthless until executed.
Good Tech Founders ARE the hardest founding team members to find.
If you accept notably less, you're always a lesser member of the team. The best founding team keeps equity and salary equal. That's the least chance for friction and resentment.
That is untrue. Mailinator definitely still supports pointing any domain to it's MX records and will allow all incoming email (modulo DoS protection, abuse, etc). Such email will arrive in the respective Mailinator inbox (i.e. bob@yourdomain.com goes to the "bob" inbox)
The discontent comes when companies rely on that as fact, and someone comes along and via masking or disposable or lots of other ways (even just signing up for a new email at yahoo or hotmail or proton or tutanota or..) , shows them it isn't true.
50Hz is one of those things you can see if you look at it in your peripheral vision, but not so much straight on.
After 5 hours I was screaming in pain my eyes hurt so bad. I couldn't figure out why they hurt and I couldn't stop playing either.
This quickly devolves into the inheritance vs. composition argument which isn't where I thought the Author wanted to go (but then sort of ended up going there). I agree with other commenters that it's an overstated idea. Inheritance is ridiculously useful in the right design structure, as is Composition. They both have a place. (Incidentally, bad Inheritance design usually looks very ugly very fast - bad Composition is often less glaring).
I find that years of designing in OOP has led me to build designs that have a goal of preventing me from making future mistakes and correctly consider implications of my code.
I find that my most immediate designs tend me towards Abstract Classes and Interfaces. While I usually get credit for "programming to the Interface" for this, that's not what usually led me there.
I like abstract methods. They (i.e. the compiler will) FORCE me to think about something if I ever decide to create another subclass of the Abstract class. The Author points out the "forget to call super" bug which is particularly nefarious and I avoid it at all costs. I can do that by providing a final concrete method which calls the abstract method. Let the subclasses implement that and never worry about super.
Anyway - governing inheritance across package hierarchies seems like a reasonable guideline. As for Inheritance vs. Composition, I don't favor either. When designing a class structure, I just make my best guess (as we'd all do) and find the structure quickly evolves on it's own. Usually, this ends up in a blend of shallow Inheritance trees with logical composition. There's always multiple Class Structures that will work - my goal is to find a reasonable one of those.
My deepest apologies for saying this, but for any type of query that has a monetization angle, I now add "site:www.reddit.com" to the query to find actual discussion about it.
Normal Reddit disclaimers apply as much of what you find is garbage but at least if you search "best exercise bike" confined to reddit you'll get real opinion not hellbent on monetizing you.
Caddy just "works" (the advent of Certs that "just work" with LetsEncrypt helped enable that).
That fills a real and important use case.
The next step would be an AI system (like the very impressive Stripe Radar (which admittedly is in a different context)) but we're not ready for that, nor would it bring us significant value over our current system. And again - we pipe things to human for things in the grey area.