Starting Out with Serverless

Back in 2017, I took my first steps into the serverless world using the Serverless Framework to deploy stuff on AWS Lambda. It was great for managing cloud resources with code. Initially, I used a bunch of YAML configurations, but honestly, YAML started to wear me out. That's when I stumbled upon Serverless Stack (SST) which, at least until version 2, was all about AWS CDK. Switching to TypeScript for structuring AWS resources? Game changer. It made everything way easier, and SST quickly became my main tool. 🚀

The Real Deal on Costs

There’s a lot of talk about AWS being pricey. Sure, it can be—but it also can be pretty darn cheap if you’re rolling with a serverless setup. Aside from paying for Route 53 for domains, I’m running a ton of side projects practically for free. Each project has its own trio of environments—dev, staging, production. Considering I’m not exactly drawing huge traffic, the cost-effectiveness is pretty sweet. Before serverless, I was dropping 20 bucks a month on Elastic Beanstalk for one webapp with zero traffic. Ouch! Imagine scaling that across all my projects now—I’d be broke! 😂

When discussing databases for serverless architectures, I often refer to DynamoDB. My feelings toward DynamoDB are mixed. On one hand, it's arguably the best fit for serverless environments, surpassing even serverless SQL databases like Neon. Neon’s free tier doesn't meet my needs. On the other hand, DynamoDB's one-table design presents a steep learning curve. It also lacks flexibility if you haven’t clearly defined your access patterns in advance. Ultimately, using DynamoDB involves a trade-off between convenience and adaptability.

Choosing Between Serverless and Servers

Serverless was all the rage in 2017, but it’s cooled off since. Some folks are ditching it for the old school server, saying serverless and microservices can make the system unnecessary complicated. Sure, if you’ve got a simple project, maybe a straightforward server is all you need, especially early on when you’re not sweating over scaling. A lot of projects never hit the point where scaling is a real issue. I think sometimes people overthink the scaling thing way too much. But hey, that’s why tools like Pocketbase are popping up—they keep it simple. 🤷

Keeping It Real with Serverless

Even though I’m chatting up the simplicity of traditional servers, I’m still a serverless guy. Why? Because it often just makes sense. Setting up a single server might be easy and cheap at first, but try juggling multiple environments—things get pricey fast. Serverless can be tricky with stateful stuff like websockets, but it’s not a dealbreaker. ⛓️‍💥

Still on Team Serverless? Absolutely.

Despite any hurdles, I’m still recommending serverless in 2024. Frameworks like SST have really smoothed out the rough edges, making it way more approachable. Running 20+ web apps for free? Couldn’t do that without serverless. It’s a killer way to kick off a project without fussing over servers and costs. 💪

Wrapping Up

Serverless isn’t perfect for every situation, but it’s got a lot to offer for the right projects. It’s about figuring out what your project needs and maybe starting serverless before deciding if you need something more traditional down the line. Flexibility is key in this cloud game, and serverless gives you plenty of that. ✨

But do they really tell us if someone can excel at their job? Not really. They just prove you're trainable. That's fine for big companies with resources to spare on training, but smaller companies? They need people who can dive right in and get to work.

The Surprising Reality

I remember being stunned by the detailed technical demands from smaller companies when I first started job hunting. Meanwhile, giants like Google were more focused on teamwork and other soft skills. Ironically, smaller companies seemed tougher to crack.

And then there's the resume. How much can you trust it? Not every company can afford to run a background check on every candidate.

These concerns aren't new. Many companies have evolved their hiring processes. Yet, when testing a candidate's abilities, we still see two main components:

• Quizzes: Check basic knowledge and prep effort.
• Projects: Showcase actual, applicable skills.

Why Quizzes Fall Short

Quizzes cover algorithm puzzles and whiteboard coding, which are popular. But are they the only way?

To me, quizzes miss key real-world skills like information retrieval and tool use. Work isn't a school exam. You don't need to memorize everything. Heck, you don't always have to be the one doing the hands-on work. What matters is delivering results.

Enter the AI Age

AI is changing everything. Companies ignoring AI in their workflows are bound to fall behind.

As a business owner, you'd want your team to harness AI and boost productivity tenfold. Just like there are computer whizzes and novices, there are AI pros and beginners. Some people just excel at integrating technology to enhance their productivity.

But again, you can't gauge this adaptability with a quiz.

That's why I believe projects are becoming more crucial. A well-designed project can showcase a candidate's overall capability, which is ultimately what matters most to a company. We don't just need exam experts; we need people who prove they can deliver results.

The Shift in Hiring

I've noticed a shift. More companies are asking these questions:

• Do resumes really matter?
• Are algorithmic puzzles truly crucial?

Sure, they're still useful for filtering candidates. Hiring managers might need to sift through a mountain of applicants. But as time passes, their importance seems to be waning.

What's Next?

So, what does hiring look like in the AI age? For software engineers, I believe project-based challenges will dominate. Candidates will need to demonstrate that they can achieve more with AI, not just let AI do the work. The goal is to show that together, 1 + 1 > 2.

I'm building a solution to answer this problem. It's called Mision Hiring and I will show you in the future. 😉

Open Interpreter is a cool project that allow you to bring LLM power to your local machine. And many peoeples prefer to use private local model instead of sharing data with cloud service.

However, for me, I don't mind to share some data and I think the cloud service will always be more powerful than local private model. And since I pay for the ChatGPT Plus already, I don't want to pay again for API usage.

So I create Actrok, a new product that bridges GPT and you local machine. It routes requests from ChatGPT to your local machine and then send the response back to ChatGPT. It is a simple idea but it is very powerful.

Join discord to get early access

Demo

Therefore, I convert my Diary ChatGPT plugin into a Diary GPT to benefit from the traffic and attention that the store will bring.

In summary, it's very easy process. Just utilize my existing ChatGPT plugin API and feed to the GPT as an action.

Diary GPT: lets you capture your thoughts in voice form. End your day with insightful summaries and analysis of your reflections.

Link

So.... Hello World! 🎉

Old site

The old site is built with Hexo and hosted on GitHub Pages.

New site

Leveraging Next.js and TailwindUI template. Hosting with SST.