HNHacker News
TopNewBestAskShowJobs

qyv

975 karma · joined May 19, 2014

submissionscomments
qyv··on SOLID Go Design
I think it is both, actually.
qyv··on “Node.js is one of the worst things to happen to the software industry” (2012)
Not every tool is the right tool for the job, and finding the right tool for the job is part of doing the job correctly.

The thing that always bugged me about node is the argument that using the same tools on the server as in the browser is somehow an advantage. That idea is not a given.

qyv··on SOLID Go Design
Could not agree more, I find SOLID often creates more harm than good with a lot of devs. For example:

S: Each class can only do one thing, ever! Gotta do something else? Lets add more classes that all inherit from each other!

O: Heh, no one even remembers this one, like, ever.

L: Ya, thats how inheritance works! Right? Right...

I: Hey, I know how to create interfaces! Interface all the classes!

D: OK, just stick the DB connection into the constructer and we've got the D covered, yesssssh!

Really though, IMO SOLID is somewhat overblown in many cases. It is just a set of guidelines for good OO design not any kind of iron-clad rules.

qyv··on “Node.js is one of the worst things to happen to the software industry” (2012)
Any developer that only knows one language is carrying around a horrible cognitive bias of how software should be written and they don't even realize it. They are dangerous, keep and eye on them, and for the love of god teach them something new.
qyv··on Why I Created YADA
As a tool for data analysis I could see using something like this, but I don't think I could ever write an application on top of this. At the low levels you are running on top of hard-coded native DB queries, potentially across multiple data sources. What happens when you are 100's of queries into a project and someone needs to change the underlying data structure? That is a shaky foundation.
qyv··on Uber’s First Self-Driving Fleet Arrives in Pittsburgh This Month
Driving without anyone in the car is still completely driverless. That human-free car will still need to navigate through the environment with hitting anyone or anything with zero possibility of intervention.
qyv··on Equation Group Cyber Weapons Auction
> Add on the fact that the author of the readme is clearly writing in an exaggerated Russian / East European accent, with such wild claims and mystery surrounding the terms of the auction...I would suspect joke or alternate reality game more quickly than a hack of Equation Group.

Without any spelling mistakes.

qyv··on Equation Group Cyber Weapons Auction
It would be reasonable to assume that the data in the auction contains as-of-yet undiscovered exploits. this also makes sense when you consider we will not likely know who walks away with this.
qyv··on Two major Windows 10 updates planned for next year
If WSL is able to deliver a real, honest-to-goodness linux experience, it will get me out of OSX and back onto windows. OSX becomes less compelling every release and the only thing that keeps me here is the *nix development environment.
qyv··on Uber is Fucked
I think this is a point that often gets glossed-over when talking about the advances in self-driving cars:

Self-driving != Driverless

Self-driving cars is largely a technology problem, and one that we have made great advances in the last 5-10 years. Driverless cars are a legal/social/political problem that we have barely started to look at yet. Self-driving is a driving tool, like cruise-control, but the human driver is still ultimately responsible for the vehicle. Driverless on the other hand places the responsibility for the vehicle, and it's occupants, onto the vehicle itself. Driverless implies that you should be able to use it while you yourself are not capable of operating a vehicle. That is a massive step, and it is something that has never been done before. All other forms of transportation, despite advanced automation, still defers to a human in the end. I would say that true driverless cars is still a significant amount of time away, despite our advances in self-driving tech.

qyv··on The Nest Cam Outdoor is a $199 camera with an easy-to-install magnetic base
Well, it will be waaaaay easier to steal.
qyv··on Apple's plan to sell used iPhones in India officially gets rejected
Perhaps the real lesson here is that buying a brand-new device every 12 months isn't sustainable. It seems like such a tremendous waste of resources that the assumed behaviour for so many is to re-buy a device based solely on the idea that it is newer.
qyv··on Foxconn replaces '60,000 factory workers with robots'
Word processors somewhat help replace the typing pool. Not to mention the affect that have had on the printing/typesetting industry. Image manipulation software allows a single person to produce far more work that hundreds of people working by hand. This is the exact purpose of software: to make people more efficient and powerful in their tasks.
qyv··on Automattic Purchases .blog TLD for $19M
Why? What intrinsically makes the value of all domains equal?
qyv··on Automattic Purchases .blog TLD for $19M
This makes sense to me. Some domain names are worth more than others. gaming.blog will probably have a lot of value, while ilikegrasshoppers.blog is not worth very much. I see no reason why these things should be assigned the same arbitrary value when it is clear their values are not equal.
qyv··on Agile is Dead
Those who say "agile is dead" are those that think agile was something you had to buy in the first place. To me agile has always just been a way of thinking about solutions to problems. It can't 'die' because it ideas have already been absorbed into our collective consciousness and affects the way we create solutions. Even if no one calls it agile anymore, the mark has been made.
qyv··on The FBI is working hard to keep you unsafe
The original argument is based on the assumption that the opposite of 'revealing 0-days makes us safer' is 'not revealing 0-days makes us less-safe'. I am not sure that is a correct assumption. On the surface it seems reasonable but it is also very simplistic. If one party knows an exploit that others do not, then that party has an advantage over everyone else, and everyone else is less safe from that party. Does that mean less safe in general? That depends on your opinion and relationship with the advantageous party. Those who feel less safe by this are the ones that distrust the FBI.
qyv··on Microservices, the Unix Philosophy, and the Richardson Maturity Model
Yes, you can always rewrite parts of a monolith, what I am saying is that it is just way easier to do with the hard-boundaries and well-defined interface contracts of microservices. You know that as long as you live up to the interface contracts, any changes you make to the microservice app cannot adversely affect other microservices. Just think about how much of software development patterns and best practices are devoted to creating proper encapsulation and avoiding tight coupling; All of that is simply built-in when you use microservics.

Yes, of course if you have great test coverage making changes to a monolith can be easier, but good test coverage and debt-riddled don't often apply to the same codebase! Lets be honest, if you are happy with your monolith codebase then there is no reason to rewrite for microservices. It is for those projects that you are not happy with the monolith code, where maintenance of the code IS scary, that the conversion makes sense.

qyv··on Microservices, the Unix Philosophy, and the Richardson Maturity Model
The part I love about microservices, and something that I think doesn't get enough attention, is that is strongly enforces separation of concerns across micro-projects. API boundaries are very clear and very rigid, it takes very little effort or oversight to prevent leaking across them. Essentially, you are moving some of the software 'best-practices' up a level form modules to applications themselves. This means that you don't need to spend a lot of effort writing great, best-practices following, future-proof, software upfront for fear of collecting horrible technical debt down the road. Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application.

And that is the other thing that I think microservices are great at: They are pragmatically easier to change. Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary, and developers are less likely to want to make changes to monoliths because of that. Microservices are easy to understand because they are small, discrete systems with well understood interface contracts. Making changes to them without breaking the entire app is not scary because it is easier to throughly understand the implications of what is being changed.

qyv··on GitHub is apparently in crisis again
A product that no ones wants is not a great product. Great software != great product.
qyv··on Why I Strive to be a 0.1x Engineer
Custom software is a business risk not an asset. Your company processes and people become dependent on workflows that lock you into the software. You become beholden to a single vendor, and eventually the pain of switching away from a woefully outdated system becomes all but impossible. Just ask the companies that still rely on hundreds of millions of lines of COBOL.

To add to this: Very old custom software located on internal systems is one thing, imagine if you are relying on 15 year old web-based software from a vendor that no longer exists. How do you protect that?

qyv··on Only 20% of people who can use Apple Pay have done so
Retailers don't support it because, like it or not, almost no one is trying to use it. And it isn't just the US, up here is Canada it is even worse I am betting. And honestly, I can understand this perfectly. I have a VISA card with chip-and-pin and contactless that I can use nearly anywhere in the world and it has a plethora of benefits that I don't get with Apple/Google payments.
qyv··on How ARM got so successful without the public really noticing
https://www.youtube.com/watch?v=1jOJl8gRPyQ

Steve Furber on the creation of ARM, quite interesting.

qyv··on Visual Studio Code is now open source
The cross-platform aspect is very nice IMO. Being able to feel at home on all 3 major platforms is great!
qyv··on Visual Studio Code is now open source
Ya, it is just and editor. I have been using it on OSX for a while now and I like it's simplicity. The git integration is also very nice.

ETA: yes it has debuggers for some languages as well, though none that I am using at the moment.

qyv··on How Apple Is Giving Design a Bad Name
Because requiring the use of two hands on two different input devices to access a feature that is not advertised to the user in any fashion is completely and utterly unintuitive.
qyv··on How Apple Is Giving Design a Bad Name
Gestures are the epitome of interface metaphors. Not only that, but their hidden nature can make them exceptionally difficult to learn or master.
qyv··on How Apple Is Giving Design a Bad Name
Speaking of Undo, one of google's common features across several of it's products is the use of undo instead of confirmation, I absolutely LOVE this. If I archive an email in gmail (app or browser) it doesnt't ask me if I am sure I want to do that, but it does give me the option to immediately undo that action. This little feature is so wonderful when you think about it. It allows you to complete an intended action in one step, but abort an unintended action in two steps. That is great functional design.
qyv··on Hidden in plain sight: Brute-forcing Slack private files
Not to mention making public file sharing explicit instead of implicit, or at least giving the option to exclude specific files from a public URL.
qyv··on All my trash for a year fit into two plastic bags
I think the reasoning goes something like this: The anus should be assumed to be an unclean portion of the body, with the exception of directly after washing it with soap and water, and should always be treated under that assumption. By using paper in between the hand and anus when wiping you are attempting to avoid cross contamination with the hands, which is a part of the body that is understood to be much cleaner. Simply avoiding contact between the two areas is the most direct route to maintain this distinction. Washing your hands with soap and water after wiping serves as a further action to maintain the usefulness of the hands.

You will notice that I highlighted soap above, I do this because I believe it is the key factor often missed in discussions like this. You can argue that hand + water can make your anus appear cleaner than hand + paper, but without soap it is at best marginally more sanitary for your anus, and significantly less sanitary for your hand. There is a reason we clean our bodies with soap and water, not just water.

← PreviousPage 5 of 7Next →