nicolasbistolfi

A $100 investment doesn't seem much and it's more like a kudos, but it is an investment. I agree that more information can help anyone determine better how to choose between startup A or B.

I've been using PushBullet for years. Great product! It's not fair what big companies are doing to what it seems to be, prioritizing their own features over third party well-built products. It's abusive.

We found that when you have a huge set of keys on Redis it is best to use SCAN and asynchronous operations or you'll block your database.

Operations on Redis utils right now are Count, Set Expire, Migrate, and Oldest Key.

Completely agree! Being remote in a non-remote company is one of the hardest things as those companies don't have procedures in place for keeping everyone in the loop.

On the guide, we wrote we have by default ALLOW ANY, DENY SOME. If you are online then you can be interrupted unless you set your status to the headphone emoji.

Otherwise posting office hours may force the idea of how many office hours each person is doing and that's not something we want to measure.

It depends on which things you need to measure based on the type of company you have or you want. A D2C company clearly needs a fixed amount of office hours where a SaaS company may not.

Remote companies come with a redefinition of what a social workplace is and how you get to know someone. In my past years, I've mostly worked remote and still I think I know the people I've worked with very well.

Communicating regularly every day and doing things like online gaming or company retreats can help to redefine social interactions.

The support system is really important, if you are remote it should mean that you prefer to be close to your support system. If you are not, then something is wrong and that's going to be a challenge.

That's why I added the CDN part, didn't wanted to go to deep on that issue. As you're saying CDN it's a big part of the image delivery, even more important than having a great algorithm to compress those images. We've found that after passing a certain threshold, eg. the image being < 200KB the download time it's not something important, so the size doesn't matter that much, the TTFB (time to first byte) is crucial.

There's also a difference between performance, speed and actual perception of speed, but that is very hard to measure and maybe it's an issue for another topic.

Totally agree with the page weight and that we're missing something. Increasing page weight when we're also increasing connection speeds is only bad when the first one increases more rapidly, and I believe that we're under that situation.

Would love to connect to chat about this and for sure I'll read the follow-up article.

Thanks for the feedback too!

I personally have been working around web technologies and performance for the last 14 years. I understand where this article is coming from and I actually have to give it some credit, it has a good click-bait title but it's an old solution. I'm tired of reading about this type of solutions, there are thousands of articles exactly like this one.

Reducing the size of your images is just the first step and there are many things you need to consider in order to make your website faster, things you need to solve: - Format: deliver the images in the right format for each browser (e.g. using WebP for Chrome) - Size: What size for each image? What happens on mobile, tablet, desktop and the different screen sizes and pixel ratios (it's not only retina or not) - Quality: Is your image being resized by the browser? Are you using raw files to generate the optimized images? - Thumbnails: Are you also generating thumbnails for listings or smaller versions of your images? How are you going those thumbs to your original images? Do you need to use a Database? - Storage: Where are you going to store those images? - Headers: Caching static assets it's key for recurrent users, are you using Apache or Nginx? Is your setup working well? - CDN: are you using a CDN to deliver those assets? CloudFlare is great but it's not the fastest way to deliver images. What about setting the right configuration for that CDN? How much are you going to spend?

So what's next? Going to one of the API service to optimize images, read their 500 pages of docs to get to resize and crop an image? Ad complex plugins to your backend and have a high dependence integration?

I mean, if you like to add more dependencies to your project, maintain more code, spends hours rebuilding scripts and running cron jobs to update your images, go for it.

That's why about 9 months ago we started working on a new concept, solving all these problems with a service that integrates as easy as a lazy-loading plugin and it solves EVERYTHING about image optimization (and yes, everything that you're talking about on every comment on this HN post).

Don't get me wrong, we have a lot to improve and there are many details of our product that we need to polish, but we believe we've built a solution that solves perfectly all the most important parts of image optimization and delivery. It's not about reducing the image size by 1KB more, it's about everything else and understanding the big picture.

We love feedback and our backlog is prioritized based on our customer needs, let us know what you think.

Here's the link to our startup website: https://piio.co

You need to ask yourself two questions: 1 - When do I need this up and running? 2 - How long do I want this stack to survive?

Question 1 Based on your skills and how fast you can learn something new, how fast you need something is crucial to select the appropriate tools to complete the tasks and you'll need that running on production (you can forget about Kubernetes now).

Based on that, you'll need to benchmark the tools you already know or the ones you want to learn based on the attributes your project will need more. Try to build a small prototype of one of the core features of your product and decide then, if you think the stack you selected is not playing along, change it and iterate on it.

Question 2 Everybody thinks they are building something to last, but that's the most stupid thing to do. Once you write the first line of code, you already set up an expiration date for that piece of software. Tools and software changes all the time and the tools you've today, they might not have support tomorrow or some technologies may come up that will solve the problem for you and you can discard a big part of your stack.

3 years is a good time for any stack to run, evolve and die. It's a good timespan to understand what you need more, build new prototypes with new technology and try new tools. So when it comes the time you've to re-build your stack, you already have something in mind.

Remember when people used two floppy disks to save files so if one floppy break you have a backup one?

I remember the first day I heard about Dropbox and I was amazed by it, it made perfect sense. Since then I'm a client and as an entrepreneur, it's a company I always looked up to.

Most of this makes perfect sense, but allow me to disagree with one point "Those kinds of decisions are much more important than what stack you build" the most technical founder should never lose focus of the importance of this. Of course, if you don't have a business it doesn't matter what stack you're using, to build a quick RAT (yes RAT, not MVP) you don't need to go deep on the stack, but once those experiments are moving forward you've to be careful. You've to pick the right stack and tools to build your company, focus on that even more if you are a technology company (not a consumer one). This won't only be part of the scaling plan of your company but it'll also play a big role on recruiting if you're using new technologies you've to train people if you're using more mature technologies you probably have a better hiring pool in one than another.

Plus, you need to be able to share with your team the importance of picking one stack over another, the cycle of development and the times to invest in refactor or why to re-build something that started as an experiment but now needs to scale.

Hello Hackers, I've been working on web development for the last 14 years and I think something is broken with image optimization. That's why we build Piio, to make it extremely easy for anyone to make their site run as fast as possible and stop worrying about images.

Piio will take care of everything, we automate the resizing, cropping, image optimization, compression and CDN integration, providing also specific images for different devices and browsers.

Piio integrates directly into your HTML, you don't need to change your image hosting or anything about your technology and it also works with all the JS frameworks.

We love feedback, so let us know your thoughts about this :)

I worked on this concept for a while, it's very interesting to work over the "fog" instead of the cloud. Calling fog to all those devices around you and connected to your WiFi instead of devices on some datacenter, it's a nice and interesting technology for distributed storage. If you think about how many devices we've and the storage available on those, it's an interesting concept to work on. Kudos to this guys.

Fore me something that inclined me to use vagrant, was the share feature, so I can let anyone in the world check my development environment. Now they deprecated that feature and https://ngrok.com does the job very well.

This should have been asked when you're first booting up. I'll receive my one plus in a few days and track whats going on. Transparency is always the best path and supports that you've the best intentions.

Some friends using apple complain about the data usage and they don't understand where the data consumption is coming from, even with the data tracking apps. Don't know what's going on with the latest versions of iOS.