I have similar work habit and, though I wouldn't say it was due to depression, I will become guilty and/or anxious when I'm in one of my low-productivity phases.
Not sure if you'll see my reply (17 hours is an eternity in internet discourse time) but I found your comment interesting. I've also struggled with this guilt/anxiety over low productivity (I think a lot of people do), but I can't decide whether the solution should be trying harder to be productive or letting go of that guilt. Or, to look at it another way: I can't figure out if the anxiety comes from a fundamental psychological need for accomplishment, or if it's a socially conditioned guilt trip imposed by a culture that stresses "reaching your potential."
I mean, what is my potential, really? What is that word actually referring to? Is it a real feature of the world? Does it simply refer to whatever the outcome is of me trying as hard as possible to develop my capabilities in some domain? And if so, is that intrinsically good, or is it just instrumental to some other thing?
Of course, when we die there are no bonus points for how many code commits we made or projects we built or companies we started. So I wonder: should I feel guilty for doing nothing? If I was able to not feel guilty about doing nothing, would that be okay too?
Threads view! Yea, I think I just get anxious that I'm simply not being productive or earning my salary. Sometimes I worry that I won't get back into the zone or be able to pull off something to make up for all the downtime.
I'm trying to just handle it by not worrying as much and accepting that I just work in spurts.
It looks interesting. I have to wonder if the sideways action of this ax is tough on the wrists? I know with a regular axe when you get a bad hit and the ax goes sideways, it's very unsatisfying - not to mention slightly jarring to the wrists and arms.
I use a maul (about 5lb head) to split wood (mostly elm since a neighbor cut down dozens of elm trees in the attempt to stop Dutch Elm disease from propagating) and the best motion I know of is to lift it straight overhead with hands spread wide. Then accelerate it downward while sliding the hand closer to the blade down to the base. Focus on coming down in a line through the center of your body. At the moment of impact, both hands are close together and your grip is just tight enough to hold onto the maul, with arms and shoulders relaxed.
It substantially reduces stress on your body and you still maintain good control. Feels like a Kendo "shomen uchi" strike.
I don't think he confuses the two - he talks about both in detail. The issue is with the concept if the flat interest rate combined with service fees and signup fees that make the advertised borrower rate misleading.
But there is a likelihood that not everybody understands it. Journalists and bloggers just throw out the 5% figure without specifying what it means because it makes for a nice sounding blurb.
It does because you were trying to insinuate that 1 hour delivery of food is a logistical nightmare. You probably are thinking more along the lines of Amazon.com and shut out of your mind that restaurants have been doing this for decades. Dominos can deliver fresh baked food almost anywhere in the country in 30 minutes.
Sometimes it's good to get a little slap that wakes you up out of startup mode.
I think it's valid to ask questions like this. We get advice all the time warning us not to try to invent our own algorithms for certain things. Obviously if we all did that, though, we would make no progress as programmers.
I'm not really an expert but it looks like this algorithm does sorting in a way that doesn't require as much extra memory as others..? I could be wrong about that, but the point is that this algorithm likely has some certain situations where it performs better than others.
#1 is a fairly standard security concept used by protocols like oAuth or JWT. It requires an API key pair (public and secret key).
The secret key is only used for signing and is never passed in the request. Used in combination with nonces and time stamps you can make a secure API that isn't susceptible to replay attacks.
Doesn't https take care of the same issue, though? And it doesn't solve the problem that if you're shipping an app the secret key can be found. So what does it solve?
You're correct - you shouldn't ship an app with a secret key embedded. That would be a flawed implementation.
It's hard to be specific without knowing what you're doing. If you have an app that connects to a third party API like Twitter, that's one situation. If you have an API that other app developers will connect to - that's a second scenario. And third is if you have an API and you write your own app to connect to it.
OAuth handles all three of these scenarios but in #1 you are a consumer, in #2 you are a provider and #3 you are both.
Check out 3-legged oAuth for an example of how to allow apps to talk to your API on behalf of a user, without that user having to give their password to the app. It's actually pretty interesting, clever and simple all at once!
HTTPS encrypts the traffic - making it difficult to sniff. It doesn't actually provide authentication though.
Even if your api uses oAuth I don't see how can you prevent the client app to steal the password.
At some point the user is going to have to give his password to someone. Can't the app ask the user for his password, keep it, and internally give it to oAuth to allow to use your api?
I meant for a native app and you being the provider. If you don't trust the client app even oAuth won't help you preventing the client app to know the user password.
There shouldn't be a key baked into the app. Each user gets their own unique key. so the worst you could do reverse engineering the app is to steal your own key. There should never be any "master" key used for all users.
Using a standard library for authentication like oAuth or similar is generally a better idea than creating your own. It's also usually easier since you don't have to re-invent the wheel.
Aside from that, I don't see a reason for an API to be able to retrieve passwords. If passwords need to be reset then the API could maybe issue a pass reset request that would email a confirmation link.
The plain text password is something that's beyond the API design, but a one way hash is generally better with an algorithm that is recognized as being secure (not MD5).
Basically, to repeat, simply not designing your own security but using recognized libraries will typically be a better idea.
My first introduction to ORMs was hibernate. I immediately loved the idea but to be honest it can be extremely frustrating to get things done - especially if you are good at writing SQL already. It can feel like handcuffs!
I kinda suspect that started the whole anti-ORM thing in response to the ridiculous complexity of some frameworks.
I still use ORMs but I've decided that it has to be a light approach that doesn't try to totally hide the SQL code from you.
In my case it just saves a lot of time on "plumbing" code. Having DB entities represented consistently as objects is helpful for doing all kinds of things. - having events fire on save or delete, hooks for business-logic validation, etc. boring stuff perhaps but time-saving and keeps things really well organized.
My ORM of choice doesn't take away the ability to write raw SQL when you want, though. I wouldn't want to use an ORM where you couldn't extend it with your own SQL.
I use an ORM that does basic mapping but let's you write your own SQL to cover situations that mismatch (still contained in a data layer of the app). It basically just saves a ton of time and let's me write a REST Services in about 2 minutes that power mobile apps or provide public/private APIs. I've used it for all variety of apps.
I certainly do care what strings get sent to the Database though, I can tell you that! If you use an ORM and don't know how to inspect the queries it generates then I'd consider that to be somewhat negligent. That's just me, though.
