l_t

I haven't used either, but I've seen Miniflux [0] and FreshRSS [1] recommended on HN before.

[0]: https://miniflux.net/ [1]: https://freshrss.org/

I don't see a strong reason for a software developer to need a phone:

- Async communication (slack/email) can be checked at your computer.

- Voice calls are usually done with your computer anyway.

- If you are on call, an old-fashioned pager can be used.

Frankly, although I do have a smartphone, I wouldn't want a job where I was required to use it, or one where I was expected to be available at all times unless on call.

If you're already "serverless" (or want to be), it's not that easy to just "add a process". Usually if you're running a process, you're maintaining one or more virtual servers, which can be a lot more operational overhead than a Lambda.

Having said that, I agree that there seems to be an inordinate amount of effort/thought going into keeping Lambdas "warm" (i.e. always running).

I think the prevalence of these hijinks indicates that AWS Lambda should consider adding a "keep running" option that ensure the particular function is always "warm", but costs a bit more.

There are a couple Clojurescript interfaces to React: Om (https://github.com/omcljs/om) and Reagent (https://reagent-project.github.io/) are two I'm familiar with.

For an example of how a Clojurescript project would be built using these libraries, I'd recommend checking out re-frame: https://github.com/Day8/re-frame

The JS code in question:

console.log([1,2,3,4,5,6,7] ^ 2);

This produces 2 because ^ is the bitwise XOR operator in Javascript. Arrays are not numeric types, so they appear to be coerced to 0 for this comparison. In short, they are effectively logging "0 XOR 2", which is 2.

I would try to think of it from a first-principles approach. You can begin with a blank slate, for instance, a single HTML file with a <script> tag. Only when "doing it yourself" becomes tedious do you start to look for libraries to solve your problem.

Personally, I find a bare minimum of tooling to be valuable. I have built SPAs using 100% vanilla JS, and it can be quite repetitive and error-prone. I'd recommend using highly simple build tooling (maybe Brunch) and an extremely simple view layer like https://github.com/Matt-Esch/virtual-dom. Pretty much everything else you can build yourself with surprisingly few lines of code -- state management, routing, event handling, data bindings, etc. I think of it as "building your own framework", and although you might not want to do it for every project, the learning experience is great.

Wow, sounds like some fascinating side effects (weirdly shroom-like, actually) that I definitely would not have expected. I guess they're vaguely related to "overstimulating" the parasympathetic nervous system.

I'm "into" mindfulness stuff as a mental exercise but now I'm feeling intrigued about experimenting with the breathing stuff (and generally the more physical aspects of Yoga) more. So thanks for the background and reading suggestions.

What kind of negative side-effects are you referring to? I've heard a fair number of people talk about high-level Yoga stuff being dangerous, but I've never really understood what they meant. Is it related to the suspension of breath, like risk of unconsciousness? Long term joint damage? (BTW, thanks for the book rec -- Kundalini Exposed looks pretty interesting).

On Android, you can open your Google account settings and disable their always-on location tracking "service". Of course, you have to take Google's word for it, and that doesn't stop GPS from working for apps like Maps when you request it.

I usually leave Location services off. I'll enable them for 5-10 seconds, get the directions from Maps, then disable the Location service again. Of course, they can still estimate my location with cell towers (or WiFi, but I usually have that disabled as well), so it's not a perfect solution. Saves a lot of battery life, though.

While I haven't personally worked at such a company, I've observed some "toxic" workplaces and found that typically it is, in fact, the senior staff who are the biggest part of the problem.

Only certain types of people achieve seniority in a toxic organization, and they are typically those who (deliberately or incidentally) benefit from the culture that everyone else hates. They build a clique and try to build influence while the new hires -- who actually care about doing things well -- turn over every 3 months.

This is all anecdotal, of course, but I do think that in an engineering-hostile organization, the senior staff should typically take the brunt of the blame (just as in a successful organization they would take the lion's share of the credit).

I don't necessarily think his comments should be ignored, just treated like what they are: childish rants that don't have a strong connection to reality.

Foreign governments are going to do what they do either way -- we are past the point of pretending that our POTUS isn't a flaming dickhead. By giving him additional attention, we're validating him as an important part of the American dialogue. He should not be that, whether he is the POTUS or not.

It's true that because of his position, he is now afforded certain powers that make him difficult to ignore. But I think his nighttime Twitter rants are just "acting out" for attention. If he was 5 years old, we would know to pay attention when he's being serious and ignore him when he's not. But we don't.

Honestly, I think at this point we just have to wait it out and try to minimize the damage he does to our society. I can only hope that the experience will be sobering enough to incite actual social change.

Thanks for this, seems appropriately cutting. The whole situation has put Twitter in a weird place, and I can understand why they don't want to cut Donald off, but it's clear that this post is just "We don't want to", but with a few paragraphs of spin. I wish they would be more honest about it.

Personally, I don't think it should be Twitter's responsibility to censor Trump. He has a way of shoehorning himself into public consciousness, and I think the public (especially the mainstream media) needs to self-censor and stop paying him so much attention. I wouldn't care if Donald tweeted whatever he wants, except that it always seems to end up in the news.

Sure -- AFAIK the problem was that Mailchimp was hacked, and the hacker was able to see and intercept the password reset links being sent to the customer by looking at Mailchimp log data. This option indicates that links should not be stored in log data, so even if an attacker has compromised your Mandrill account, they should be unable to see the exact reset links that are being sent.

edit: worth noting that there are obviously other ways a hacked Mandrill/Mailchimp account could be abused. This just shuts down one of the major abuses you could perform.

It's the opposite. That is a link to the section of the Mandrill docs, not the Mailgun docs. The view_content_link option fixes the security problem. (In theory, anyway).

I'm also not a DB expert, but I definitely think locality is a concern with UUIDs (at least in Postgresql, which stores records in sorted order).

But, storage locality has always struck me as a use-case-specific optimization, in the sense that it's hard to take locality into account without knowing what traffic patterns the table is expected to experience. So, although UUIDs provide locality for exactly no types of queries, that may not be a problem for you.

For instance, you could use an autoincrementing sequence, but that only provides good locality for queries over sequential records. The COMB method would provide good locality for queries over time periods. But if you aren't performing those types of queries, you might be better off with a different type of PK.

Good point. I imagine most smaller companies are specifically looking for people who can build things in a self-directed environment using the latest tech. Maybe it's only the larger, older orgs that care about legacy code wrangling.

In my limited (n=1) experience with startups, I'd say they take a very different approach to recruiting and should be "courted" by the applicant in a slightly different way. Relevant experience becomes more important. IMO, startups particularly care about:

1. Can the applicant hit the ground running? Startups don't want to hire people that need training, because they want them to be productive ASAP. Startup teams have very little slack, so individual productivity is more important. For example, I started working at a large company and had 3 months training before I touched any code. Then I went to a startup and pushed a bugfix to production my first day. The expectation is quite different. My recommendation would be to work on some side projects that use common startup tech stacks (Ruby, Node, Python, etc.) so they know you're familiar with more than just Java or whatever, and emphasize how you're a quick learner that adapts easily to different situations.

2. Does the applicant offer a specialization we need? Startups are always looking to increase the quality and range of their technical skillset. If you have a relevant specialization that their engineering team is lacking, like DB admin, security, hiring, management, distributed systems, AWS, etc., the startup will be much more inclined to hire you. Recommendation here would be to try to dig into some topics and gain expertise in your current company that can carry over. Alternatively, something like getting an AWS certification, publishing blog posts about relevant topics, etc.

3. Is the applicant a culture fit? For example, usually startup employees should be internally motivated, autonomous, good communicators that enjoy programming and think of development as a vocation instead of a chore. You shouldn't have to be exactly the same as everyone else, just show that you're likeable, flexible, and can do good work without a manager.

(edited: Added some additional clarifying points).

How so?

(edit: I wonder if we're talking about slightly different things here. The "notes" I'm referring to are primarily code commentary -- the same kind of material we cover in pair programming. As far as I know, we don't share notes about our internal decision-making process, which perhaps is what you're talking about.)

Whether or not you feel proud about them, I would suggest trying to look at some of your accomplishments from a different perspective to see how they can actually be impressive. Things like cleaning up terrible legacy codebases are valuable and reflect two positive traits, to me: Willingness to get your hands dirty, and the sense to distinguish between "good" and "bad" code.

On the other hand, if you really just want to build more "pride-worthy" things, I think you really just need to prioritize that desire more. Making something you're proud of often means going beyond what's mandated by "useful and sensible". This might sound a bit inane, but I would seriously consider asking yourself, before you start your next project(s), "How can I make this project something I'm proud of?"

IMO, there's an ethical upside as well. Doing the right thing is its own reward, emotionally speaking.

Well, it depends. At my job, we do give feedback to all our candidates. Basically, we condense our notes about the candidate down to the most important points and send it to them. We've found that candidates appreciate getting this kind of feedback because:

1. It gives them a kind of closure and treats them with respect.

2. It can help them improve for future applications.

Usually, the reason is not "Someone else is a better fit". We're not just trying to fill one position -- if we find good engineers, we'll hire them. Usually feedback is related to stuff that came up in either the coding project or the interview. It helps people in the same way that code review helps them: by giving them an opportunity to learn and improve.

Devcards is great. A good alternative for non-CLJS apps is storybook: https://github.com/storybooks/storybook.

If we can distinguish "progressive" and "regressive" ideas through reason, that can only happen with an open discussion that gives both sides' advocates equal, fair treatment.

If an idea is universally considered regressive, then usually it doesn't come up. Ideas that people are discussing are usually ones where it's not completely clear yet, to everyone, whether it is a good idea or not. In that case, allowing both sides fair advocacy is critical to making a fair decision.

Can't agree on number 2, because it's a false dichotomy. The gender imbalance cannot be simplified to being because of any one specific cause (like a difference in personal interests). There is a whole cluster of causes, including:

1. Malicious actions by men. This undoubtedly happens, let's not pretend otherwise. However, it might not be very common.

2. Non-malicious but annoying behavior from men directed towards women. This could include unwanted flirtation, accidental condescension, inappropriate jokes, etc.

3. A male-oriented culture. Even if the guys don't act in an annoying way, being in a significant minority is usually less appealing than being in a situation where you have a more even gender split.

4. Boys and girls are nurtured in different ways, which can drive them towards having different interests as adults.

5. Biological differences between men and women. Personally, I think this is one of the least important factors, and it's also the only one that we can't change.

Whether or not (5) is an issue, (1-4) can and should be addressed, so that women who are naturally inclined to CS are not nudged away from the industry by their life experiences.

The problem with Bash functions is that they aren't really functions -- more like subroutines. You can't even return a value from a Bash function (just a numeric status code).

Most of the functions the author wrote wouldn't even be possible in Bash, if only because they utilize return values. So your suggestion that he "compare similar programming styles" is practically impossible without using implicit state-passing methods in Bash, which are much more awkward and error-prone than real functions.

Having said that, I agree that writing scripts in Python adds a lot of overhead over Bash, and should only be done if you are implementing significant complicated logic more than just I/O. (For example, retries, exponential backoff, business logic, exception handling, etc.)

I notice this as well. I think a lot of it comes down to modern society being so complex that most people are unwilling or unable to do anything "extra" like that, at least not regularly. Not only that, but companies and governments are so complex that they resort to bureaucracy as a way to attempt to make things predictable.

Every action people take is driven by such a complex web of incentives these days, that risk-aversion is often seen as the pragmatic option.

Having said that, I will say that I am often pleasantly surprised by how thoughtful and considerate people can be to each other in general. But I do think that risk-averse "fuck you" treatment is on the rise, especially when dealing with people at work being asked to make difficult decisions. Risk aversion is corporate policy.

Interesting that I don't see a single positive comment here. There's definitely an absurd amount of marketing-speak, but this seems like a good idea to me, and a logical progression for Creative Cloud. Photoshop (and probably other CC products) has a ton of places where a little ML could make things way simpler for the user.

Although it is funny to think that Adobe is starting to become a data company in order to add features to their products.

An assertive person could easily say, firmly and with confidence, that "I don't have an opinion on this topic, because the evidence isn't definitive." If you can't do that, then there is something in your scenario that's incompatible with intellectual honesty, but it's not assertiveness -- more likely, it's a feeling of needing to satisfy the expectations of others that you will have an opinion. That feeling is like antimatter for intellectual honesty, but it's totally different from assertiveness.

Unless you want to focus exclusively on Web development, I wouldn't recommend picking Javascript as your first programming language. The ecosystem is fragmented, and the language itself is probably not the best for teaching. Have you considered learning Python or Ruby first?

On the other hand, if you're committed to Javascript, I think you should start at the most basic level. Angular is good, but it's a complicated system that takes time for even experienced Javascript coders to get used to. Same with Express, Mocha, Grunt, etc. These tools incorporate complexity to hide it from the programmer. But as a novice programmer, you DO NOT want that complexity hidden right off the bat.

Assuming you've gotten past the very basics (syntax of programming language, executing Javascript in the browser, reasoning about simple scripts), I would recommend the following as an exercise for learning:

Pick a fairly simple website and try to re-implement it, without looking at the original code. Don't start with angular, bower, or anything else. Just Javascript, HTML, and CSS. This is the fundamental language all browsers speak, and you have to be able to understand it for everything else to make sense.

As you work on the project, you might start to find things annoying. Like, dynamically changing page content with Javascript requires a lot of code. How could you make it easier? Think about, and possibly even implement, a solution that makes sense to you. Then, once you don't need it, you can reach for a pre-baked solution (like Angular, Vue, or React in this case).

Excuse me? Did you even read the NYMag article you posted? Allow me to provide some quotes:

"Now, as Hoffner and Salon surely know, things live forever on the internet, so you can still read the original Nickerson article here. And doing so makes it clear that Salon took a silly, overly risk-averse approach here, likely caving to a chorus of voices who willfully misunderstood the article. That’s unfortunate, since this was a brave and important article to publish — one the site should be proud of rather than try, futilely, to toss down the memory-hole."

Later:

"No reasonable reader could construe this as pro-pedophilia. Nickerson is explicitly saying his condition has hampered his life immensely and that he is simply hoping to scratch out a decent existence without hurting anybody. That’s the entire point of the article — nowhere does he defend sexual contact between adults and minors. Why, then, was his article deleted? It sounds like Salon won’t ever provide an explanation."

After reading your comment, you're the only one that's coming off like a propagandist.

I think (good, thorough) documentation is probably a good example. Unnecessary early, when everything is in flux, but critical later, when there's too much for one person to know.