147 karma · joined May 11, 2017
So many guides online, and the uninitiated can rarely differentiate between a good one and an outdated one. I’ve used a good one in the past but can’t think of it right now.
By the way, I know you can print and just rotate, but for display and orientation purposes, the bottom right corner should be a white square.
Simply: achieving the highest profit margin for LTL loads across a range of factors + route optimization.
- building an application to assist with dispatching. Dispatching in the current state of the world is a human heavy process with a lot of phone calls. The application was built to make it easy to pick the correct shipment opportunities.
- paying for fuel and hotel stays. Fuel (other than labor, the drivers) will be your largest cost by far. Also, hotels for drivers that aren’t driving sleeper trucks (trucks with a built in sleeping cabin). This happened rarely but did occur when we took shipments late in the week. For the uninformed: never pick up a shipment on Friday, as it will likely extend over the weekend and your truck will stay full over that period.
- paying for trucks. Whether you rent or buy, the trucks have to be paid for. If you are brokering shipments only (as a broker vs as a carrier) this won’t be a cost
With 500K you can afford to buy several freight trucks. All you would need is 3-5 trucks to start turning over real profit. The rest of the employees can be dispatchers. The trick here is finding drivers as they are in high demand. Dispatchers are easily trained.
I’ve bootstrapped a similar logistics business with less than $10,000 USD and had good success within the first 60 days. Licenses and certifications can be done in 2-3 days and is a fast way to have a business fully certified and up and running.
I built something in a similar spirit to your comment and this larger thread, albeit a bit simplistic. Lets you document and write your bash scripts in a markdown file, then you can run the blocks. It figures out what arguments you expect in a block and turns them into CLI flags. https://github.com/khalidx/runbook
Not sure how useful it is but I use it to maintain a collection of documented bash scripts.
- a plain old Lambda HTTP handler function - a function that reacts and responds to api, queue, and table stream messages - a function that is configured as an express app - a function that writes to DynamoDB
“Custom interpreters are powerful and flexible tools that allow solving thorny problems with grace.
The general idea is that distilling the fundamental building blocks in library form makes it possible to reduce needed effort to the point where more problems start to look like custom languages, and where it's affordable to try out new ideas and throw some away.”
- from the repo README
Do you use AWS Lambda? Do you deploy stuff to the cloud?
Maybe you're like me and you've tried it all...
- AWS CloudFormation - AWS SAM - AWS CDK - Terraform - Pulumi
There are so many ways to deploy infrastructure.
Sometimes, you just want to get a strong, scalable API or function out there, whether for a new product you're building or for a simple webhook.
This project makes that possible, and gives you a strong, reliable starting point for your infrastructure that you can build on and won't have to throw away later.
Instantly deploy functions to the cloud. It's the fastest way to get a scalable service up and online. A powerful infrastructure abstraction built with the AWS CDK.
As long as you're logged in to AWS, you can deploy your functions and infrastructure with a single "npm run deploy".
Each function you add get's its own HTTP API route and SQS Queue, giving you multiple ways to send events into the Lambda function for processing.
More things are coming. I hope you'll enjoy this simple programming and deployment model as much as I have.
PS: This is NOT a library, SDK, or a product. It is a GitHub starter template project that you can clone/fork, with ZERO configuration.
I deploy stuff to the cloud all day, and find myself spending hours just writing the initial IaC (infrastructure as code) config and getting everything wired up correctly. This template gets me going pretty fast with a running API, sending requests to my functions. I can also send work to my functions (or between functions) asynchronously with a queue. All with just a single-command to deploy everything.
Needless to say, this saves me countless hours.
I hope it is useful for you all as well. I always get so much value out of HN, and am wanting to give back. Free forever + open source. Concerns/suggestions are welcomed!
Enjoy and thanks for reading.
It generates: - a node module - native binaries for win/mac/linux - a docker image - and optionally an ECS cluster ...from a simple Node TypeScript project, with a single build command.
The origin project just contains a boilerplate express app, that compiles to native binaries as well as a Docker image. The boilerplate contains an infrastructure as code config as well to get you deployed to an ECS cluster fast.
Supports running locally and deploying a production ready HTTPS containerized service rather quickly.
Can also be easily ported to target any cloud, or Lambda and other serverless runtimes.
This has greatly increased my productivity while building "microservices" or whatever they are called these days ;). Hope you can benefit and enjoy as well!
Thanks for reading.
Here's a simple, stays-out-of-your-way tool for deploying an API in 30 Seconds to AWS API Gateway.
v1.5.0 is here, which brings cool features like generating a terraform file or postman collection from your API resources, so you can pick up your workflow in other tools.
This is a repost of what I shared 10 months ago: https://news.ycombinator.com/item?id=20322759
resource-x is a simple CLI tool that gets a full CRUD API up and running in AWS in under 30 seconds.
I design APIs all day, and find myself spending hours just writing the initial Swagger API specification file.
With this tool, I just have to define a couple of schemas in a Markdown document, run generate + deploy, and I'm up and running in AWS with an endpoint I can hit. Needless to say, this saves me countless hours.
I hope it is useful for you all as well. I always get so much value out of HN, and am wanting to give back. Free forever + open source. Concerns/suggestions are welcomed!
Thanks for reading.
Country-size tire fire. That's funny.
But your statement is 100% true. Every dependency in the node ecosystem and on NPM seems to have a hundred and one sub-dependencies, which each in turn have a hundred and one more. It would be most efficient to write a CLI application in something like C, Rust, Go, Nim, or something similar.
This starter project is less about the "best and optimal way of building CLI applications" and more about "building CLI applications with TypeScript".
Many developers feel at home with TypeScript and this just puts everything in one place to enable them to build CLI applications with the language they love, and the rich NPM package ecosystem they depend on.
Thanks for your comment!
I got a lot of love last time I shared an open source project on HN (and by a "lot" I mean 20 stars on GitHub, HA HA).
The point is, I always get so much value out of HN, and want to keep giving back. Here's a starter project template to get you going building cross-platform (Windows, Mac, Linux) CLI applications using plain-old TypeScript or node!
I write lots of little CLI applications and this gets me going pretty fast with a running CLI, a place to write tests, and a single-command to build everything.
Free forever + open source. Comments/concerns/suggestions are welcomed!
Enjoy and thanks for reading.
Maybe I'll rename it before it goes viral and I become famous ;).
Really, what drove the creation of this tool and its particular way of doing things are the following motivations:
1) It takes a long time to write a Swagger document by hand (2-4 API operations per resource, 5+ resources on average = 20+ operations)
2) The normal swagger file is 200 - 1000+ lines long. Most of the swagger documents I write (even before including documentation) easily stretch past 1000 lines.
3) To avoid writing 1000 lines of code by hand, this tool lets you define just your domain models, as JSON schemas. If you write the objects that your API will expose, the tool will generate the operations and the swagger code for that automatically.
4) Now that the swagger file is generated, I can fill in documentation and make other changes before deploying.
5) The reason the schemas are in a markdown document is because it easily exports to HTML or a PDF, and is shareable to non-technical users and other audiences (business/product owners/architecture) and keeps everything tidy and in one place.
I agree that having the raw JSON/yaml files are probably easier to work with across tools or as input to other processes. I may add this in the future.
Thanks for giving me the opportunity to explain.
I've opened a GitHub issue to track this item. I should be able to get it done by the end of the week.
Check this link to see my progress: https://github.com/khalidx/resource-x/issues/1
Thanks for the suggestion!