HN user

jdost

18 karma

[ my public key: https://keybase.io/jdost; my proof: https://keybase.io/jdost/sigs/Po3bV8BdrJhJ9U2owTeXIZftU6NJObevZbGoyRu4WS4 ]

Posts0
Comments28
View on HN
No posts found.
Amazon Echo 12 years ago

To be fair, the portable devices are not yet monitoring all conversations due to battery life constraints. If it were a wall powered device, I would be very wary of it, but until then it seems highly unlikely it can achieve that behavior and not drain the battery in a noticeable way.

To follow up with this. You could add `conky -c json.conky | while read json; do echo $json > /opt/http/monitor/info.json; done` to your start. Then just static serve the `info.json` file and it should update at whatever interval you set for conky. No dynamic execution though (hard part is that lack of interaction).

Great read! Upon finishing, the two sides seem to be opposite solutions of a good problem (that is getting a non singular path to guarantee code quality). It seems that the best solution is a mixed approach. Using pairs to gain the benefits of knowledge sharing and sort of check ups (that is having a second pair of eyes to achieve the intermediate commit/review issue). But also using a large amount of solo coding with code reviews to ensure overall quality without missing out on the non-pairing types.

Has anyone ever tried a balanced approach like this? Such as spending 2-3 days each week pairing on a part of a project to help with knowledge sharing, best practices, or possible bad paths, and then the rest solo coding with some final code reviews?

Also, what is the best form of code review? Is it having a single developer be assigned to perform a code review for each pull request or for it to have some gestation period for crowd comments to come in, or even some voting quota/discussion until a simple consensus is reached? There seems to be some room for a variety of time/quality trade offs (in theory, more eyes == higher quality, more time).

I am curious if this has any relation to their recent acquisition of Braintree Payments. If they are instead using Braintree as the payment gateway, it could work out very well for the participants.

Moto X review 13 years ago

My friend that works at Motorola says there were frictions in having Google brand their own company's flagship phone as a Nexus device. Probably a lot of hard feelings still between Google and Samsung (among others).

Well it came out with the latest one (the CF exploit) that they were gagged on it when the FBI got involved. They eventually came out about it when the gag was removed, but only so much. When the FBI gets involved, usually the transparency get tossed out the window, at least if the company is not one of the giants.

It is more a combination of the small and vocal user base and the message it sends to them about Google being open to cutting any product that has a usage they don't think is significant. Those people who see Google cut a product that they have adopted into a regular usage will probably add an asterisk to any recommendation for adopting a new Google product. There is no certainty that the lifespan of that Google is dedicated to that product. With the shutting down or Reader, it sends a clear message that almost no product of Google's is safe and that we should all be wary of what of theirs we adopt into daily usage.

Think smaller 14 years ago

This is something I view along with the "Ship it" idea. When I work on any project, I try to think of what the minimum is for the project to reach the real alpha stage. Where it is at least usable. Only then do I begin to entertain the various notes I have made on additional features or details.

I always go back to the sentence: "The best camera is the one you have". Finishing something and getting it out, no matter how much it lacks in terms of features, is important. The best way to finish is to keep it simple (or small).

Interesting idea, the interaction would get very difficult with more pictures in the stack. Also lacks a way to work in mobile. But you are really onto something here, would be interesting to see how this can be improved!

I disagree, jQuery is more of a compatibility layer. Think of it (in a way) like an ORM for various SQL backends. They allow you to change between different SQL implementations without needing to learn the various nuances of each engine. The same can be said for jQuery, allowing you to modify classes even though browsers implement that DOM property differently.

I actually attended the talk this is from, the concept of recipe writers vs abstractioners is not aimed at the actual developers but at the tools and how they are developed. His idea is that the tools should be built around aiding developers in their need to abstract the data (Bret Victor talked a lot about this as well).

It isn't the information they can view, it is the things they can do impersonating you. Any application installed on your phone can probably access the two authenticating pieces of information. Then they can impersonate you in messages to, say, your parents and say something like "Hey mom, I need to order something, can you send me your credit card?" and then your mom, under the illusion that WhatsApp is secure, will send it right over.

While this is (from my experience) incredibly inaccurate of the programming community at large. My fear is that it will encourage a perception of people looking for a career to embrace this stereotype. People who read this article may think "This is awesome, I definitely want to do this!" and a new wave of people who think that "brogramming" is the norm will begin to seep into the industry. Maybe the numbers will not be that much and it will allow a more diverse culture.

Oddly, in the age of the internet, it is easier for someone to do open source at least part of the time for their employer. With the internet, a lot of the money for web based companies is not from the software itself, but the services the software provides. This allows for the company to open source a large chunk of the code base and still make money to pay the developers. (see things like 37signals/RoR)

I use a Macbook Air (Mid 2011) and run Arch Linux on it. Works fine, only thing that doesn't work is the Thunderbolt port. I picked the Air because the model was on its second year and had a history of people having Linux run on it. The touchpad works fine with xf86-input-mtrack, which lets you customize some of the finer details on the trackpad. ... Just my two cents.

I think the biggest thing he emphasized is the fact that you can never be "The Best Programmer" because there is always something to learn and ways to grow. That is probably one of the keys to a good developer, they know that there is still plenty for them to learn.

I don't use Facebook. And whenever I go to a site that requires Facebook credentials to comment, I just don't comment. It does not bother me because that is a choice I made in not using Facebook as my online persona. But that is the truth to all this. I do not blame Facebook for their design of the service, I am the one to blame for not wanting to adhere to them. And I get to live with the consequences.

And the freedom they have is choosing the services they use as well. If a service wants you to use your real name and you don't want to, you don't use the service. That's the beauty of freedom, you are not required to use a service like Google Plus. Freedom is not that Google Plus is suddenly a governed body that has to adhere to some unwritten law that they cannot require real names.

Well the complaint is somewhat moot. The programming he is discussing is professional, where it is results and business driven. If every time a company wanted to develop a product that uses a database, MVC framework, web server, etc, the programmers had to write some of those components from scratch, it would be a nightmare. It would take much longer than necessary and probably be riddled with security holes. This is not a sound practice for business.

If people are looking for the creativity in developing some of these things, they can do it in their free time. That is the beauty of programming, all you need to do it is a computer, keyboard, and monitor. There is nothing stopping someone from going home and writing a database over a weekend.

I would think it could be beneficial to be able to streamline the .js file for people (think like jQuery.ui) so if I were developing something not in Japanese, the additional (and for me, useless) methods would not add to the code size, (assuming that there is not some incredible interweaving between the methods).

A few points I got from this:

- Possessions do own you. I have made an effort in the past year to minimize my stuff. One of my long term goals is to be able to shrink the majority of my life into a travel-able size. It allows me to cherish the essentials and not bloat the rest of my life.

- Money does allow for happiness, just to a certain extent. Money opens up many opportunities and comforts. It also adds security. If my car gets totalled tomorrow, I know that I have enough money saved up to be able to handle it, rather than suddenly be put in a dire situation that could jeopardize my job.

- Major goals are important, but not everything. People work towards things, its natural of humanity. Everyone sets goals and works towards them (or sometimes waits for them) and it is a strong driving force in our lives. But sacrificing your happiness now for the sake of those goals is counterproductive. You need to enjoy the time used to achieve that goal. You shouldn't look back on the year(s) taken to get to the point and see a lot of unhappiness and pain, enjoy some of the time instead.

- In regards to the internet/tv posts, I would say that the biggest thing anyone can do is read. The Internet provides an incredibly accessible portal of information and using it to learn new things (and an incredibly breadth of things) is a tool everyone should use and abuse.

... Just my random thoughts after reading the post.

Actually, in my recent job hunt (in Chicago no less) I saw a very even distribution in RoR and Django centric jobs. I believe outside of the Chicago area, it may even move towards a more Django dominant role. I am unsure of whether this is due to the abilities of the framework or if Python is more accessible and widely used a language than Ruby.