Me too! With Sendkeys and some Win32 API calls, I wrote an AOL add-on (available through Keyword: addons) called AoLOL!. It was my first software business.
Q: How do you identify the AOL window?
A: Look for an app with titlebar = "America[space][space]Online"
And BeOS/Haiku with the "Hey" command which does literally the same, but far more than key input. You can interact with widgets too.
Under Unix, there's xdotool and friends.
It's not a two-factor code like you're thinking of. That code is shown on the sign-in / account recovery page, to whoever making that attempt. Then the same value has to be chosen on the mobile device that's being used to authenticate that sign-in.
The goal isn't to protect against phishing or social engineering, but against people accidentally approving a sign-in they didn't initiate.
(specifically, there are "credential stuffing" style sign-in attacks where an attacker logs in "suspiciously" at the same time as a legit log in, possibly after forcing a log-out, hoping you approve both your log in and theirs when you get two, or ten pop-ups)
The attacker was going through the sign in flow on their own computer. In the MFA step, it shows you a number and asks to you press the same number on your phone.
I spent some time playing around with this recently and loved it at first. I also realized ChatGPT is pretty good at generating Mermaid diagrams (didn't try your own AI features).
However after getting into it some I ran into some significant frustrations. After creating a medium-complexity diagram, I was excited to see the Whiteboard feature to drag things around / improve the layout manually. But it really started breaking, it just wouldn't let me organize/drag things where I wanted, and I couldn't get things to not overlap. I also wished more diagram types supported Whiteboard (I noticed some didn't).
Also I some confusion between the capabilities of mermaidchart.com and mermaid.live. Are these competitors? Variations of similar apps. I was confused. Also "Playground" vs "Live Editor" is confusing.
Overall glad this exists and hope it continues to improve.
I hear you on the whiteboard. It's still in its early days. Should be substantially improved in the coming months.
To clarify on mermaidchart.com and mermaid.live, we are the same team. Mermaid.live is our fully open source hosted editor. This was the original editor for our 10 year old open source project. The creator of Mermaid recently founded mermaidchart.com with the CEO of Gitlab's venture studio to expand the capabilities of Mermaid for more users and build an enterprise grade product. The company is open core and venture backed. The Mermaid project will remain forever open source and will continue to invest in growing it and the company for those that desire more advanced business features.
We really appreciate your feedback and support. Ping me if you'd like to chat with our product team about the features you're hoping for:) andrew@mermaidchart.com
Please forgive my posting on the broader topic of Mermaid... The Mermaid package has gotten much bigger recently. Compare mermaid.min.js across a sampling of major releases:
All the new features are really cool, and maybe this is "fine" when mermaid itself is the purpose of the website (like this submission), but it's a bigger burden when mermaid is a value-add for generic markdown documentation: every visitor has to download and execute 3+MB of js just to view simple diagrams, or worse even when there are no diagrams on that page at all.
Is there a plan to reduce the required bundle size for viewers and users that only use a small subset of mermaid's wide feature set?
> it just wouldn't let me organize/drag things where I wanted, and I couldn't get things to not overlap
I suspect this might be a fundamental issue with mermaid. I've always had issues getting it to lay things out in any other way than how it "wants" me to, with giant gaps between things
This is definitely a gap in current Mermaid functionality. This is a gap we're aiming to close in 2025. Significant Whiteboard improvements and expanded diagram support is on the way! If you have a specific use case or diagram type you'd like us to keep in mind then let me know! dominic@mermaidchart.com
At Close we have been offering an 80% salary / 4-day week option for engineering roles for a few years now. This originally was mandatory during early 2020 COVID-19 economic uncertainty as a way to cut costs without doing layoffs. Quickly it became optional – most people moved back to 100% but some people decided they enjoyed it and wanted to continue that arrangement.
What's interesting about 4d weeks is that it's 20% less work but 50% more days off, which can be very impactful for folks.
Our 80% option is a flexible thing, as in you can choose to do it for the summer but not the rest of the year. We try to adjust workloads accordingly. I've taken advantage of it myself for a period of time and it gave me more free time to be with family and also work on side projects.
Some people really love taking our 80% option / 4d and others absolutely don't want to.
Companies offering flexibility in work hours can really help retention IMO, and is a natural progression after (a) remote / freedom of location, and (b) freedom of specific work schedule.
I know a few companies offer "4-day week summers" to everybody or even "everyone always does 4-day weeks". But I like the "fairness" of giving people an option, since different people are in different life situations at different times where working more vs. less can be especially helpful.
> This originally was mandatory during early 2020 COVID-19 economic uncertainty as a way to cut costs without doing layoffs.
I'm surprised I've never heard of this solution before. I think it's brilliant, especially for engineering roles where we can still make rent on 80% pay.
I would gladly move back and forth between the options as I get more or less burnt out with work, or take on a new extra curricular.
The core Lexical library is really a framework for building such editors. However, we also provide many common rich-text features out-of-the-box via separate packages, such as @lexical/rich-text. We also expose bindings for React (and hope to have them for other frameworks soon). Check out the lexical-playground package on GitHub for an example of how you can create a rich-text editor by adding plugins to the LexicalComposer component in @lexical/react.
As a hiring manager at a startup-ish SaaS company:
I love seeing side projects, both because
- it shows you have entrepreneurial skills (care about and able to think about more than just code)
- as well as the technical side (shows you’re able to build from scratch, probably work across the stack, etc.)
Show off as much as you can:
- leave the websites up even if the business isn’t viable. Better to be able to see and play with a side project versus just seeing a line on a resume and having no idea how significant or good it was.
- open source what you can. It can be very helpful to point to code from real projects you wrote, especially if you have a gap in employment.
Try to foster great references. Even if they aren’t recent, you will do better if you have a few raving fans.
Unless you had a lot of management experience, I suggest trying to find a job as an IC. More open roles / people seem more desperate for developers. If you’re good, it won’t matter much if you have a gap. Personally I prefer to hire ICs who have a little management experience because they tend to be better employees as well as are more likely to be someone who can eventually lead/manage with us as well.
Overall: the biggest thing is you want to show that you have been doing good technical work over the last few years versus just some unemployable person who had “projects”.
I’m hiring frontend/React and backend/Python engineers: phil@close.com
As a customer of Stripe too, I almost[1] couldn't disagree more.
Running a global online/SaaS business is hard. So much complexity everywhere. I wish Stripe would handle MORE problems & complexity and would happily pay for it.
Just a few examples Stripe could handle:
- Checkout + Portal is a great start, but it still takes too much (expensive) design+dev brainpower to create the entire experience of a high quality trial-to-paid and existing-customer billing management in a SaaS app.
- Running a SaaS company at any scale is full of Support headaches that Stripe Dashboard simply does not handle well - stuff like tweaking a billing date, and doing combination (e.g. wire transfer + credit card) payments, "can you re-send my invoice but with my VAT ID on it this time?" and many more. At any scale, lots of effort is spend on custom billing support tickets and building internal tooling even if you use all of Stripe's features.
- Are you a SaaS company selling all over the US? Good luck being complaint with all 50 states in terms of sales tax reporting without expensive legal/accounting help. Did you hire any remote out-of-state employees? Good luck -- now your financial compliance got even more complicated.
Stripe doesn't do any of these things well today. And if they did, it would likely be much cheaper than the in-house solutions everyone is coming up with instead. I think Stripe should handle 10x as much complexity for a SaaS company than it does today, and of course they should get paid for doing so.
[1] I agree it would be amazing to see Stripe come up with smoother flows for supporting payments that bypassing the expensive card network's fees.
Fully agree, I don't have a problem paying Stripe if it means they are properly incentivized to help me run my business.
I'd be happy to throw them a few more percent if they could handle more of the complexity you've mentioned above. Right now, Stripe is both too complex to set up and too simple from a feature perspective.
I'm optimistic though since it seems companies like Paddle, Chargebee and others are blazing that path. As much as I love Stripe and what they originally did for online commerce, they're already starting to look like the lazy incumbent compared to the challengers right now. Market dominance is not a great incentive to create better products.
I'd suggest putting the information directly on your site (at least the IPOs coming up in the next X days) and charge for the deeper access + email notifications. But that way people have a reason to visit your site even if they haven't decided to pay yet.
With an 8 year old codebase w/100s of thousands of lines of code and 100s of dependencies, this was no easy task.
We had read many of the blog posts about the Python 3 transition, and yet still had a number of surprises. Here were some of the more interesting ones.
https://learn.microsoft.com/en-us/dotnet/api/microsoft.visua...