A bigger smartwatch has a lot more space for a battery.
1,169 karma · joined August 15, 2014
But if you're going after a niche market -- a computer vision-based tennis coaching app, for example -- your valuation will necessarily be lower than a company with broad appeal.
So instead of saying, "No, that's a small market" you could invest at a lower valuation and still make the same or higher return as with a unicorn.
It will help me, so thanks in advance.
- Becoming a power user of spreadsheets, with formulas, pulling in external data (like forex rates), basic statistical analysis, conditional formatting to present a conclusion (green is better, red is worse) etc.
- Running a VM on AWS, SSH, basic Linux administration, etc.
- Automating manual tasks like cropping 500 JPEGs and rotating them. This could use Automator on macOS or a Python script.
- Writing small throw-away programs in Python. For example, I have a noisy signal, noisy due to errors in measurement. Would averaging with a second noisy signal reduce or increase noise? I wrote a simple Python program to generate two random arrays, measure standard deviation of each, and print out whether the resulting array has lower standard deviation than neither, one or both the input arrays. I then repeated 100 times to eliminate variability caused by the random number generation.
- HTML / CSS / JS to build a simple web site.
- Exploring emerging no-code tools (Airtable?)
Hardcore techies often don't have these skills. That would be like a surgeon who can perform open-heart surgery but can't administer first aid.
I've been been interested in photography for a long time, first with my Sony mirrorless camera. Like everyone else, I moved to smartphones but found them lacking for the kind of photography I wanted to do. I looked around, and there were some good apps, but none did exactly what I wanted. I kept experimenting with computational photography algorithms, running an experiment one weekend with a billion pixels, for example. I built Futurecam from this exploration, and did fun things along the way like GPU-accelerating and optimising our algorithms to process 1GB of data every second on an iPhone!
I built Futurecam not to be a replica of an SLR in software form, but to do things an SLR cannot do. For example, Futurecam's Liquid Shutter lets you change the shutter speed of a long exposure after capture. You can play with this live on our web site futurecam.app. Futurecam also has a light trail video which, again, you can try out on the website. And more.
Try it out for free, and if you know anyone passionate about photography, let them know.
Different people expect different things, so the expectations in my post can't obviously be interpeted as universal.
> Many of the “reality” parts are not always true, too
Which is why they're phrased as "often" or "sometimes" or "can happen". Not "always happens". If I've forgotten to add such a qualifier somewhere, please let me know, and I'll fix it.
Put differently, any platform needs a critical mass to survive, and if they price it so high, it won't have that critical mass, causing it to die, in which case the development cost would be wasted.
Surely people in the 80s weren't so dumb as to not understand network effects, so what am I missing?
I'm not asking about ad- / content-blockers, because that issue has been discussed many times and there's no value in rehashing that discussion. I'm asking about OTHER TYPES of extensions.
To measure how secure the resulting code is, have a test suite of malformed packets or other input and see how many of them the code in each language handles.
Why don't you get stuff out, determine what needs to be improved (if any, as opposed to starting a new task) and improve that?
If you put out a marketing video for your app, and it drives 1000 purchases of your app, you should be proud of that. The video itself is irrelevant, so don't judge it, or yourself by it.
I think the craftsman analogy is misleading because physical objects can't be updated after selling. Maybe a better analogy is that of a chef, who doesn't measure himself by how it turned out when he tried a new dish for the first time. He measures himself by how it is after repeated iterations.
As Basecamp says, work should always be compared with what it was before, not a theoretical ideal.
In fact, if you can't argue for their side as well as they can, you haven't really understood it, so you shouldn't argue.
Where can I find statistics on how many metro stations are in operation today vs a decade ago?
From a project management point of view, native is the least risky. Yes, it takes more people, more salary cost but you know it will work. The last thing I want to find out after six months or an year that our strategy isn't working and we need to rewrite things. Risk is worse than financial cost or time. That is, I'd rather spend a quarter longer or X rupees more if I know I'll get something working at the end of it.
Regarding pixel well depth, I suppose we can have a sensor with greater pixel size and low pixel count, like a 3840 x 2160 sensor in a full-frame camcorder. Since this would be sold as a video-oriented camera, lack of higher resolution will be a problem problem than in a still-oriented camera.
I suppose concise / implicit is fine when the thing that's being hidden can't go wrong, like in:
[i * 2 for i in 1...10]
The loop counter increment logic can't possibly go wrong, so it's fine to not think about it.
Regarding error-handling, don't you want to think about? If you're calling a() followed by b(), what should you do if a() fails? In some cases, b() shouldn't be called, but in others, it should, like deleting a temp file. And if you have to think about it, it's better to be explicit?