bokglobule

Arguably the Rust language is a replacement candidate for 'C' (and C++).

Amen. IMO the root of all evil is compiler "optimization" of code. If you really, really need the wee bit of extra performance through optimization, hire an expert at ass'y language and optimize the bit that matters. Rarely is this the case, especially with business apps.

I've seen my fair share of bugs from the compiler incorrectly hoisting variables from loops, mis-using registers, etc. I prefer to turn off compiler optimization as one of the first steps in a new project, but that's me.

Ah, maybe not. Watch the film "A Good American". It's out on Netflix.

People are people. Govt employees can have agendas that are bad for the rest of us just like contractors.

Agree. Some of the complaints get back to not really understanding the ES6-7 feature set that was created to allow JS to become more compact yet expressive in doing common tasks (like creating an object from an existing object, yet changing a few parts).

For the Redux issue, the light bulb went off for me at one point on how best to use it to solve specific issues. React is focused on component based development of the UX; everything in the small library is there to help with this including "state" (that is, the internal logic state of the component). Since React went with the simpler one-way flow of data updates (vs. Angular's two-way), Redux came along to help bridge the divide between clusters of components that share some data.

So when designing React apps, I almost always use React state. 80-90% of the time it's fine, works well and is easy to understand since everything about the component is there (along with the "props" or arguments to the component).

I use Redux when I occasionally need to do the following: 1) Share data between otherwise unrelated components 2) I need to setup "global" state that exists between page transitions, etc. 3) A child component needs to notify a parent of some event. This can also be done with a simple callback provided as a prop to avoid Redux in this situation.

So think of this in two levels - local component state within a nest of related components, and shared state within a set of unrelated components; the latter is where Redux can help.

I much prefer (and find simpler to understand) that state is local and changes one-way. It's similar to the issue whether a language supports reference types as parameters or sticks to value types. Reference types make it easy to pass along side effects to the caller, but it can also introduce hard to understand side effects.

The tech industry keeps repeating the same business mistakes. This period strikes me more and more of the 1998-99 era when there was so much euphoria that there was no way but up. Then March 2000 came, the first Internet high flyers started to fail, and very quickly the whole thing unraveled. We're on the same road again...

The latest stats I've seen for us here in the DC metro area are that we have 7 of the 10 richest counties in the U.S. That tells you a lot about the density of opportunity here. The downtown areas have gentrified amazingly in the last several years. Nice place to be if you want to be close to things.

I was in Seattle recently and it's a truly beautiful city with a stunning landscape. But seemed kinda sleepy compared to DC. I was in Silicon Valley also recently and came away scratching my head why anyone would wish to live there now - miles upon miles of industrial parks, seemed kinda run down even in Cupertino. But just my 2 cents.

What people really mean here is that when you consume real fruit, you get fiber, vitamins, other micro nutrients and, yes, fructose. But the quantity of fructose you get is relatively small. When people drink fruit juice, basically all they are getting is the fructose (with water). And you're getting many apples worth at one time. This overloads the liver which starts turning the fructose into fat.

So eating an apple or an orange is fine. Drinking fruit juice is not. Hope this helps

Frankly I think people are insane to use any of these password manager products, whether SaaS or local. You're trusting a 3rd party to exercise control over your most sensitive digital information. Since the majority of people on HN are developer-types, you'd think "we" would write a little code, if necessary, for ourselves to make it easier to remember passwords. Basically a little DIY.

IMO, this will end badly.

It's precisely the fact that Coconut oil is 100% plant-based, saturated fat that it IS healthy. The notion that saturated fat causes heart disease has been thoroughly debunked as sham science. It's the inflammation in the arteries stimulated by excess sugar consumption (refined carbs, table sugar, soda, etc) that causes the problem. The body sends cholesterol to the scene to patch the damage.

Reference: http://www.nytimes.com/2002/07/07/magazine/what-if-it-s-all-...

Best analogy I've heard is "Gee whiz, everytime I see a fire, I see firemen. I guess firemen cause fires". Cholesterol does not cause heart disease all by itself.

You'd think scientists and the media, by this time, would have stopped relying on Dr. Ansel Keyes for their rationale for what causes heart disease. His 1950's "Seven Countries" study was an example of cherry-picked data to support a pre-determined outcome that was desired.

Reference: https://www.theguardian.com/society/2016/apr/07/the-sugar-co...

Finally, I can show you cultures, such as the Inuit, who's diet is almost exclusively saturated fat and protein and which are healthy (as long as they stick to their native diet). I challenge anyone to show me a culture who's diet is primarily sugar-based which has comparable health.

Reference: http://www.theiflife.com/the-inuit-paradox-high-fat-lower-he...

Actually I think this self-learning approach is a great example of what it takes to be a great developer regardless of background (or formal training).

http://signaltower.co/jennifer-dewalt/

She built one project each day for 180 days learning a bit more each day. She chronicled her mistakes and successes. HN had a post on it at the time and the majority of developers that responded were very supportive.

I think the behavior of today's media is perfectly understandable if you substitute some terms. For example-

Instead of "stories" think of "memes"

Instead of "reporters" think of "salespeople"

Instead of "readers" think of "customers"

Instead of "publishers" think of "businesses"

With that map in mind, it's not hard to understand why many, not all, but clearly many do the shoddy reporting that they do. Like so many things in today's world, it's no longer about pride in your craft, but instead it's about making money. The result is it's increasingly difficult for the average person to tell the real news from the fake because the traditional sources of real news have abandoned this in favor of sensationalism. But on the upside, the Internet may yet save us by providing smaller outlets a chance to provide better reporting. I was very much intrigued by the WH using Skype to pull in reporters from smaller cities and areas that don't normally get a chance to participate.

<rant> During the recent Trump news conference, another aspect of what's going on jumped out at me. At one point in the news conference, the camera pulled back to show the room of reporters. What I found jarring was the age of the reporters; to my eye they looked like they were high schoolers. I was hoping to hear well thought out questions but instead most of them asked the same robotic questions on Russia. I don't think the media organizations are doing the American people (and the world) a great service when they send the least experienced staff members to events like this. </rant>

With respect to the OP, I think remote work is the wave of the future. We've been doing it in my large company (financial software co) in a large US city for over a decade. As communication technology has improved (video chat, SaaS apps like Slack, Github) distance has become no barrier... with some caveats.

We've found it works best when:

Near timezone- Remote people are in the same or near timezone as the home office. This makes it easy to align the work day, schedule meetings, etc.

Remote shared location- making sure a group of people who work remotely have access to a shared location where they can work together has worked far better than people working from home, coffee shop, etc.

Culture- as I write this I'm in a large open floor plan style office. All of the lead devs are chatting away with their team members located in Canada and S.America. We love the ability to pull people in easily and work as though we are all here. Frankly, we talk to the "remote" people in video chats more often than many of the people in other departments. When the day's over we head home to families, sports, etc.

It doesn't work if..

-Your culture stresses in-person interactions during and after work.

-You don't have a culture of trust.

-Your company won't pay for great communication apps & technology including lots of monitors.

-Your team works at home and is distracted by kids, spouses, etc, etc.

Frankly as tech gets better I think that one day the idea of moving to a large city like SF, Austin, NYC, etc for work purposes will be seen as ridiculous, outdated and needlessly costly. Likely there will be shared office hubs in small-to-medium sized cities around the world where people can work with other people in similar remote hubs.

Always insightful..

They added support for lazy loading React modules. Helpful for large SPA-style apps. https://webpack.js.org/guides/lazy-load-react/

I've noticed a steady movement by companies to treat anyone with X number of years of experience as "senior" rather than their capability. Your definition is far better but harder to gauge compared to years of experience (likely why they do it this way).

Northern VA, DC area. Some of the best schools in the country.

very cool..!

That can happen if 1) you have an older dimmer not rated for LEDs 2) the dimmer is mis-wired; some are very specific where you hookup the hot and load wires especially if you have a 3-way circuit for the light.

In my case, it was a controlled experiment. I was suspicious that it might NOT have been wheat so I let it run for this year too and so far so good with pollen season almost over. Of course, the real test would be to consume large amounts of wheat this year, wait til next spring and see if the allergies return.

Never said it was, just a personal viewpoint. But just because there are no long term studies doesn't mean that's safe. In the U.S., we assume products are safe unless proven otherwise. In Europe, they have to prove they are safe before they are available. GMO manufacturers and scientists submit limited studies on their products to the USDA which is why they are OK in the US, but rejected in Europe.

To your point, yes people have always had allergies but I can only speak for myself. I didn't have them as a kid, didn't have them as a teenager or young adult. I developed them in the '90s and now they're gone by eliminating wheat. My wife also had the same experience. Just a data point, but to discount it out of hand isn't much of an argument.

FWIW, I was able to clear up my spring time pollen allergies by not eating gluten.

I was tested for celiac disease, but I do not have it thankfully. However, I decided to stop eating wheat in early 2015 for other reasons. I noticed that when spring came, I had almost no issues with pollen. I mentioned it to my internist and he said he wasn't surprised given the typical immune reaction to gluten. This year, another repeat performance. Almost no problems with pollen season. I had one or two episodes where I sneezed, but that was it. My area of the US is one of the highest allergy areas due to the density of foliage.

As to why this has happened, I can only speculate. I suspect that it's mostly due to the fact that the wheat we eat in the U.S. isn't the same wheat we ate 40+ years ago- it's been genetically altered and there are NO long term studies on the affect of these GMOs on health - they haven't been available on the market long enough to really know. I haven't tried eating non-GMO wheat products so I can't say whether my theory is correct. For me, not eating wheat was the way to go for better health overall. But.. I do miss eating warm bread from the oven now and then.

If you're interviewing for a job for you, treat it as though you are interviewing them. Do they ask good questions? How do they respond to yours? Are you having a conversation more than an 'interview'? Ask them to describe the ideal employee- the answer might surprise you. Trust your gut instincts. If something seems "off", run.

If you're interviewing people for a job you're filling, focus on getting them to do a small test project and bring it in for the on-site. I've done this for years, never had someone say no. Worst that happens, they're too busy and back out. Fine, no worries. Works well for developers, release managers, program managers, technical writers, etc. Basically you want to be sure that they can solve problems. Memorized knowledge of facts has almost no value (to me) these days; things are changing way too fast for that to matter in the long run. Never understood why the Google's, Microsoft's, ask the goofy questions like "why are manhole covers round?". To me, the hires that are a joy to work with are adaptable, learn things pretty fast, take pride in what they create, show leadership by helping others in their group, and are dependable.

Do you guys worry about confidentiality with these services?

The trouble is that many devs can't see past that 80% to see the 20% that's left. They whip up a little app at night, it works really nicely and they assume this means the app they're working on during the day should be "rewritten" in the framework-du-jour. Then they hit that 20% "wall", blame the framework as "lame" and start hunting for an alternative. Rinse and repeat.

Last year I got excited about NodeJS and started working with it quite heavily. Then I started to see holes - difficult debugging, so-so tooling for development, mixed bag of JS components, and so on. I then stepped back and realized that although it was interesting, and I can see it useful for some specialized server-side development, I don't see it as compellingly different than current alternatives (Rails, .NET, PHP, etc) to try to build a whole web app with it.

To extend your argument, I would state that frameworks are only about speeding up the initial creation of an application that fits into a narrow set of assumptions. Frameworks, by their very nature, capture a set of decisions by their designers about how an app should work (or behave). As long as your app fits nicely into this box and you can live with the downstream risk that maybe it won't one day, then go for it.

You're right about making sure the problem is gauged to the time available for the interview. I had my senior and lead developers work through the problem individually to see how long it took them. Typically, 10-15 minutes. And they didn't see the problem ahead of time. Wasn't meant to be tricky, but rather do they understand a basic data structure we use all the time in the context of a simple problem.

Personally, I don't buy the complaint that asking a candidate to write some code is unfair although I've had a few tell me so. For onsite interviews, I have them spend a couple of nights ahead of time working on a small web app with a few moving parts (UX, DB, validations) to see how they approach writing larger, more real-world code. They demo the app, then show me the code. Some people take real pains with what they do, fully understand what they used and why, and can talk about how they'd improve it if they had more time. Unfortunately, many don't do that for one reason or another. But this tells me what I/we need to know before thinking about hiring someone as a developer.

Actually, asking people to write some code in (or for) an interview is the best way to go with technical interviews. I haven't found any other approach that's better given the time constraints for an interview (and I've been interviewing ppl for 20+ years).

The hard part is coming up with what programming problem to ask a candidate that's fair to the candidate yet provides insight into their capability. For us, I created a simple data structure problem that hits a smattering of things that are taught in a typical undergrad CS curriculum (trees, recursion, etc). The candidate has about 30min to write the code for this in their preferred language using a plain text editor. I care less about perfect syntax when working with libraries, etc. and more about whether the candidate can take a problem statement and turn it into working code.

For an on-site interview, I send the candidate a description (along with screenshots) of a small web app project that hits some UI, some DB, some business layer. I encourage them to innovate around my description and surprise me. They get a couple of days to implement, then show up with their laptop and demo it. I want to see working software, then a deep dive into their code.

Typically by the end of the on-site interview, we have a really good idea whether this person knows their trade or not. It's helped me sniff out the pretenders pretty well over the years. The ones I hire are the ones who obviously take pride in their craft, know why they picked various implementation approaches, and can explain the technology they used.

Azure has greatly improved over the past 12 mos. Only good news for us developers the more that AWS and Azure compete with each other.

It's made me consider going back to Firefox from Chrome.

As a developer who also knows plumbing (and other trades), I'd beg to differ. When I talk to neighbors and friends, most of whom are highly "technical", they look at me in disbelief when I suggest they resolve a plumbing (or carpentry or mechanical) issue on their own. I get the "I have no idea where to start", or "I don't have any tools", and so on. It's not a lack of available information, it's the fear, in many cases extreme fear, of the ramifications of not "doing it right": a flood in the house, a wall that collapses because you hacked through a supporting structure, an electrical short that burns the house down, and so on.

You build a website and maybe it doesn't work right (has bugs). In most cases, no one dies or gets hurt. You mess up plumbing, electrical, etc and that's not the case at all. It's easy to look down on the non-technical trades since we live in a time that glorifies (like the OP says) the art of programming. But next time you have a major plumbing issue, your heat pump goes on the fritz, you car dies on the highway, consider how helpful it is to know RoR, Java, C#, etc. Not too much...

Microsoft Excel can do this (or Google docs if you prefer) assuming you setup the formulas to do the calculation. Pretty simple IMO. Some people prefer a more formal project system like Microsoft Project. A web app that is popular is Basecamp by 37signals.

If you have an existing app, you can try this: http://www.projectcodemeter.com/cost_estimation/kop1.html