Arguably the Rust language is a replacement candidate for 'C' (and C++).
155 karma · joined February 25, 2013
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.
People are people. Govt employees can have agendas that are bad for the rest of us just like contractors.
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.
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.
So eating an apple or an orange is fine. Drinking fruit juice is not. Hope this helps
IMO, this will end badly.
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...
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.
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>
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.
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.
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 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.
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.
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.
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.
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...
If you have an existing app, you can try this: http://www.projectcodemeter.com/cost_estimation/kop1.html