Especially on the timestamps, I find some of the design choices a little bit bizarre. Choosing only a strict ISO8601 format: awesome! Choosing to excise critical parts (representing timezones and fractional seconds): very unfortunate.
Chesterson's Fence (https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_... is a very powerful design principle. They chose to put those elements into ISO 8601 for principled reasons: they come from pain. They embody responses to mistakes that I've made, and thousands of other engineers before me. Unless we fully understand the reason they were included, don't arbitrarily to do "I haven't used it, so it must be useless."
Other than that, it looks like a clean spec, but I'm not personally convinced that it has enough incremental value over JSON or YAML to replace them in the human-readable exchange format space. It can be a little more concise, but if I'm making something for humans, clarity (typically) has more value than conciseness. Are there other compelling values that I'm missing?
HN won't let me reply to the parent, but I thought your model minority myth was potentially interesting.
In this case, it just doesn't stand up to facts. Yes, Asians have greater income disparity, because the top 1% of Asians are way at the top 1%. According to the U.S. Census (https://www.census.gov/data/tables/time-series/demo/income-p...) in every single year, Asians have out-incomed White and all-race averages in the 20th, 40th, 60th, 80th, and 95th percentiles.
That's a pretty compelling picture of "Asians make more money than whites," full stop.
There are three disciplines that come together in the tech industry: programming, computer science, and software engineering.
Programming is the act of writing programs, and is a skill like any other. Some folks are good at it; some people struggle with it; most people can do some of it if they learn and try hard enough. Programming is what creates value for 95% of the jobs in the tech industry, and if you get good at programming (and programming on a whiteboard) you'll do exceedingly well.
Computer science is the theory of computing; it is a branch of mathematics. Djikstra is famously (wrongly) attributed with saying "Computer Science is no more about computers than astronomy is about telescopes." Many (but not all) amazing computer scientists that I've worked with are terrible programmers and software engineers, but their value has been outsized. Any good programmer can integrate a Raft library into your code for consensus. The computer scientists are the ones that not only apply the correct CDRT theory to your custom-built database, but can prove that it converges consistently.
Software engineering is the practice of delivering the right software on time and on budget; good software architects think in terms of software engineering. In the 1980s, when computers were going in to _everything_, military projects were at the forefront because Reagan ensured that we were spending mad cash there. It was like the dot com boom of the 2000s; you just couldn't go wrong bidding computerized systems. Because they were new, the contracts were cost-plus, and the military-industrial complex screwed the federal government blue with cost overruns. Anything with software on it typically had budget overruns in the 500%+ range. Not wanting to be screwed blue, the Feds reached out to CMU and said "How do we stop this?" So together they built the Software Engineering Institute to put some science and best practices around delivering software. And the SEI screwed them blue, coming up with CMM and a bunch of other bad ideas, but also some good ones along the way.
When thinking about the skill sets of the teams I'm putting together, those are some primary aspects I look at, and the ontology by which I think about them. Of course, there are lots of specialties in each of them, and many people have experience and skills in several of them.
It depends who you're talking to, of course. The goal of language is to create shared understanding, so you need to have shared definitions, whatever they are. Nobody else shares my definitions, so I mostly keep them to myself if I'm not pontificating.
If you're speaking to a recruiter, you are whichever one of them pays the highest. If you're speaking to an academic, you're a computer scientist (perhaps a mediocre one). If you're telling your mom what you do, you're a software engineer because it makes her feel good.
Let's go back to the end of the story, where Satoshi was found, not by the work of a community coming together in peace and harmony, but by creepy-ass Clearview-AI wannabe spyware that was fed the original photo and matched it cross the collective surveillance of third-party photos on the internet.
Does that not strike anybody as a little bit unsettling?
That is the reality we live in now. Clearview is a nightmare and no one cares. Par for the course. If the NSA has been spying on us for years then why does it matter if a private company is doing it too?
Aurum197 - Mrs. Gregordv has been looking for this since 1999. We've been waiting for someone to make BT headsets that can be real jewelry for semiformal affairs. We figured someone would make a bluetooth version of Elektra King's ear cuff (https://ibb.co/xJbkQs8), and make an absolute mint. The market has been slow to catch on.
While I'm sure you have some good design acumen, I'm with others in making sure that the visible part is an easy-to-integrate standard so you're not a blocker on the fashion side. I'll happily pay a premium price for the BT side of it, but you're not going to be able to produce enough variety to suit everybody's tastes. If I can have my jeweler create custom fittings, then I can make them whatever I want.
Gregordv, by "the visible part", you mean the earring, right? Aside from the size constraint (driven by the size of the battery and the height of the speaker,) the number of earring styles is not an issue (since the module is detachable.) Does that address what you were saying or did I completely miss what you were saying? Our plan is to introduce several styles on an ongoing basis much like any fashion brand. These earrings can be worn with our without the module.
But - the missus is fond of wearing white gold, gold filigree, maybe some earrings with sapphires. I don't expect that she's necessarily in the initial market you'll be addressing.
While I can imagine you'll have a variety of styles, you won't be able to produce enough styles to match the breadth of the market. It would be a shame if your growth were capped by how many axes of preference you could address with your limited resources. You definitely want enough to bootstrap the market (and you mentioned that part of your business plan was to be able to sell additional earrings to repeat customers), but I suspect the long game is in creating and licensing the standards for mating the active components and the earrings. Other companies may be taking part of the pie, but as long as it keeps growing exponentially, there's plenty for everyone.
Yes, you can make your own earrings and wear with this module! (Though our earrings have a feature on the reverse side that make them a slightly better option.)
I always push my devs to really study the Bittorrent protocol. The elements of the protocol are all fairly easy to understand, but it's gorgeous to see how elegantly it solved a social problem rather than a computational problem. The tit-for-tat and fast-finish protocols are incredibly graceful ways to create virtuous cycles in a social/technical hybrid, and replaced very real vicious cycles in previous protocols.
Various TCP backoff algorithms are also a great study in how to approach problems with insufficient knowledge of the system under test, and building desirable properties (reliable in-order delivery) from a undesirable input (arbitrary packet loss, and loss in the face of congestion). I make all the kids try to implement their own, then walk through the history of TCP approaches to the modern day.
> The elements of the protocol are all fairly easy to understand, but it's gorgeous to see how elegantly it solved a social problem rather than a computational problem.
One more protocol / paper which fits this description, imo, is Bitcoin paper [0]. It's easy and accessible to all and elegently explains how to solve a complex problem with existing tools. Not sure it can be called as an 'algorithm'
It worked pretty well. Used it for several years until I started making real money and decided I could buy things rather than pirate them.
I had only been coding for a year or two at that point, so it is probably filled with lots of odd choices, but it also isn't super optimized like I would guess the more well known clients might be, and so might be easier to parse.
I'm the same way in that I haven't been using torrents in awhile. But a few legit things they're used for us Linux distros so if you ever feel like helping in that endeavor you can seed out some ISOs.
I use the Seiki 42" 4k TV which hovers around $300 (http://camelcamelcamel.com/Seiki-SE42UM-42-Inch-Ultra-Black/...) as my primary development monitor. As a TV, color-correct, or a gaming monitor, it's rather dross, but as a wall of pixels to work on code, I will never go back to anything smaller. Ever.
You dont. At 42 inches a 4k screen is basically four perfectly aligned 21 inch HD panels. Don't think 4k for smooth fonts and "retina" style pixel density. Think of it in terms of screen real estate.
Sitting an arms-length away, I'm just imagining a lot of head movement going from the bottom (dock or taskbar) to top (menu bar or window title bar). Any tips? Maybe it works if you put only less-frequently-used windows up high.
I've used a 30" display (at arms-length), and it felt nice, but already rather tall.
This is really interesting but yeah it almost seems like overkill for my use case! However I may be editing some 4K video too in the future (from a drone) so maybe this is the way to go.
Chesterson's Fence (https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_... is a very powerful design principle. They chose to put those elements into ISO 8601 for principled reasons: they come from pain. They embody responses to mistakes that I've made, and thousands of other engineers before me. Unless we fully understand the reason they were included, don't arbitrarily to do "I haven't used it, so it must be useless."
Other than that, it looks like a clean spec, but I'm not personally convinced that it has enough incremental value over JSON or YAML to replace them in the human-readable exchange format space. It can be a little more concise, but if I'm making something for humans, clarity (typically) has more value than conciseness. Are there other compelling values that I'm missing?