yusufnb

Interesting term that is in context of AI - "teleoperation". Sends a chill thinking about that world. But also the inevitability of a plausible future.

Web based mobile made sense pre AI. It is just simpler now to use different languages and have AI implement features across the board.

What does a site build cost, in real $$ with Opus vs Sol? Could you share a ballpark?

Hi HN community, founder here. Please take few minutes to drop your feedback / comments / suggestions here. Also, comment on the onboarding flow. Thanks.

Hey HN, we are still in beta and resolving the rough edges. But please try it out. Leave any feedback here or email me - yusuf at sleekcms. Thanks.

At my work I interview a lot of fresh grads and interns. I have been doing that consistently for last 4 years. During the interviews I always ask the candidates to show and tell, share their screen and talk about their projects and work at school and other internships.

Since last few months, I have seen a notable difference in the quality and extent of projects these students have been able to accomplish. Every project and website they show looks polished, most of those could be a full startup MVP pre AI days.

The bar has clearly been raised way high, very fast with AI.

The code is vibe-coded. Not the content. Which I think is more important for a blog site.

I have always liked Astro. It also works great with AI tools since its combination of markdown and code. Was able to vibe code a quick blog template and deploy to cloudflare in minutes with an existing headless backend - https://sleekcms-astro-blog.pages.dev/

Just use TypeScript frontend and backend. For backend, use Node+Express+TypeScript. If doing anything in ML, create a service in Python, but keep application code in TypeScript.

If you are doing full stack development, this works much better. The npm ecosystem is amazing. You can create common libs, share types, don't have to context switch and all future developers can do some full stack.

This is the boring stuff, but works and scales.

Sucks. More than the system it's the silly woman who called the cops. Instead of helping the child she did a great disservice to him and his entire family.

I had a similar hiccup when I first came to US when our apt neighbor called cops because my 1 year old was screaming. Crazy, I know.

This country thrives on fear - health, insurance, legal, weapons - the biggest money making industries in US all feed on fear economy.

There is a great poem call "If" by Rudyard Kipling. I feel it defines pretty well the traits of a happy person.

Best to do it as exempt or retainer. Hard to build or do anything creative while counting hours.

DM me yusuf.nb @ gmail, I might be able to help.

Google did encroach. Google office/docs is much better than Microsoft. Chrome OS is a better OS for most non-tech jobs. The browser is the operating system for most people, and Chrome is leading in that. They won on mobile as well with Android. Google Workspace, in my opinion, is much better than Microsoft.

It's their outdated search bringing everything else down it seems.

Email - it brought the world closer in a way it was never before.

That's capitalism. The optimization function works towards maximizing profit over value.

For a $2 sandwich, I would need to sell 100 at $3 to make a $100 profit and just 10 at $12 to make the same.

I needed a specific ID-based ordered tree implementation for a project. Amazing that ChatGPT was able to write the entire code, unit tests, and documentation for it.

Taskivities

https://taskivities.com

PS: I was looking for an app to track time against a list of value adds. More like daily task related activity logs with option to add time. So we built this internally and later launched as a SaaS.

I think the whole point of creating a company should be to provide value in a sustainable manner. And you need to make money for that. So the end goal should be to maximize value and not money.

When money becomes the main goal, companies eventually turn on evil side.

I considered using it some time back for API payload validations. I found it bit too verbose for my use case then. I ended up writing my own lighter version and it worked pretty well. I later open sourced it here - https://github.com/sleeksky-dev/alt-schema .

Here's an old video where Eric Schmidt mentions Google's goal of being like ChatGPT (in a way) - https://www.youtube.com/watch?v=XeIIpLqsOe4

Google changed its course along the way!

We recently moved all our projects to Node. Few thoughts -

1. The TypeScript tooling with Node has improved tremendously. Frameworks like Nest make it simple to work with it.

2. There are some really good frameworks that, over the years, have remained simple and just work. Example - Express, Sequelize, etc.

3. Same developer can make changes on both the frontend and backend since the language on both sides is TypeScript now. That simplifies building features as less coordination is required for full feature development.

4. Deploying Node apps is overall simpler. Be it VMs, containers, or serverless. Horizontal scaling is cheap, and most applications don't need much processing optimizations there.

So many good answers, and interesting to read the overall technology landscape. The technology debates can be endless, though. I think it's good to consider a few non-technical aspects as well for selecting your stack -

1. Is this stack popular among recent similar successful products?

2. What technology will make it easier to find relevant talent?

3. Does your stack allow for rapidly changing code along with a rapidly changing team? This is important, especially in the early stages of development.

4. Are you trying to do things the Google way? Facebook might never exist had they started with C++ instead of PHP.

5. Do you want to be on the cutting edge for the sake of being on the cutting edge?

I elaborated on this a bit in my blog here if interested - https://sleeksky.com/blog/technology-stack

Based on alt-schema - https://www.npmjs.com/package/@sleeksky/alt-schema

Better docs is a TODO. Please see example.js .

Few things I have always wanted in a search engine -

- Filter out news/SEO'd sites. Better if by default. - Specialized categories - software dev, real estates, travel, garden, finance, .... - More weight on verifiable authors. Eg. blogs, publications, good quality social media posts (quora, reddit, linkedin), etc. - Geo-temporal-social context in search. Able to navigate results by time and space easily.

Also, might be good to have search engine interface be like an app than a website. The secret search features should be upfront and interact-able.

Remote work is not the same as out-sourcing. Out-sourcing was a necessary evil and only worked for large/mature companies with carved out business processes that could be offloaded. These companies were never remote-first.

With companies being forced to modify their internal processes to be remote-first, what they will realize is that remote does work once they align to it. And once they realize that, there is no stopping them. Since the benefits of having a remote first company well aligned to working efficiently far out-weigh the benefits of a co-located team.

Strings make it easy to define as configs and can be implemented uniformly across different languages. In world of microservices, a Python and a Go service can easily share the schema definitions via some config files. Also strings provided the best minimalist syntax.

Its updated now to work with ? syntax

I think we are talking about different things here. I love OpenAPI and wouldn't do a project without it. verify-json is a lightweight way to validate JSON schema and does not intend to change/improve anything about OpenAPI.

This is more for client-server JSON schema validations, comes handy when different teams are writing client and server side code. Especially in startups where iterations are rapid.

Updated to ? in 1.0.3

I understand. In my experience, the usability of those standards is pretty bad. Which in effect leads to projects not using anything at all.

One of the benefit of JSON over XML is that it is concise and fast to work with. The standard should reflect that part as well.

With this lib, as a developer to verify a JSON for a simple REST request is as simple as - `verify(json, "{a,b,c}")`