No, not in 24 hours. In about 2 hours. The laundry list of things - api validation, error handling, db migrations, good naming - it's pretty routine. A person writing production apis will have no trouble integrating all of it in a very short period of time. This is after all what we do everyday. If a candidate thinks not having sql injection in the code is an explicit requirement or is going to take a lot of time, then that is not the person for the job.
Here is a pretty simple flask implementation of your laundry list - api validation, db migration, no sql injections, no n+1 queries, good naming, swagger ui...
from flask import Flask, jsonify
from flask_sqlalchemy import SQLAlchemy
from flask_migrate import Migrate
from flask_apispec import use_kwargs, marshal_with, MethodResource, FlaskApiSpec
from marshmallow import Schema, fields, validate, ValidationError
from sqlalchemy.orm import joinedload
# setup
app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///dev.db'
db = SQLAlchemy(app)
migrate = Migrate(app, db)
docs = FlaskApiSpec(app)
# Return validation errors as JSON
@app.errorhandler(422)
@app.errorhandler(400)
def handle_error(err):
headers = err.data.get("headers", None)
messages = err.data.get("messages", ["Invalid request."])
if headers:
return jsonify({"errors": messages}), err.code, headers
else:
return jsonify({"errors": messages}), err.code
# models
POST_TITLE_LENGTH_MAX = 80
POST_CONTENT_LENGTH_MAX = 5000
class Post(db.Model):
id = db.Column(db.Integer, primary_key=True)
title = db.Column(db.String(POST_TITLE_LENGTH_MAX), nullable=False)
content = db.Column(db.String(POST_CONTENT_LENGTH_MAX), nullable=False)
comments = db.relationship('Comment', back_populates='post')
COMMENTER_LENGTH_MAX = POST_TITLE_LENGTH_MAX
COMMENT_LENGTH_MAX = POST_CONTENT_LENGTH_MAX
class Comment(db.Model):
id = db.Column(db.Integer, primary_key=True)
commenter = db.Column(db.String(COMMENTER_LENGTH_MAX), nullable=False)
comment = db.Column(db.String(COMMENT_LENGTH_MAX), nullable=False)
post_id = db.Column(db.ForeignKey('post.id'))
post = db.relationship('Post', uselist=False, back_populates='comments')
# schemas
class CommentSchema(Schema):
id = fields.Int(required=True, dump_only=True)
commenter = fields.Str(
required=True, validate=validate.Length(max=COMMENTER_LENGTH_MAX))
comment = fields.Str(
required=True, validate=validate.Length(max=COMMENT_LENGTH_MAX))
class PostSchema(Schema):
id = fields.Int(required=True, dump_only=True)
title = fields.Str(required=True, validate=validate.Length(
max=POST_TITLE_LENGTH_MAX))
content = fields.Str(required=True, validate=validate.Length(
max=POST_CONTENT_LENGTH_MAX))
comments = fields.Nested(CommentSchema, many=True, dump_only=True)
# dal
def get_post_list():
return Post.query.all()
def get_post(post_id):
return Post.query.options(joinedload(Post.comments)).get(post_id)
def create_post(title, content):
post = Post(title=title, content=content)
db.session.add(post)
db.session.commit()
return post
def add_comment_to_post(post_id, commenter, comment):
comment = Comment(commenter=commenter, comment=comment, post_id=post_id)
db.session.add(comment)
db.session.commit()
return comment
# views
class PostListResource(MethodResource):
@marshal_with(PostSchema(many=True))
def get(self):
return get_post_list()
@marshal_with(PostSchema)
@use_kwargs(PostSchema)
def post(self, title, content):
return create_post(title, content)
class PostResource(MethodResource):
@marshal_with(PostSchema)
def get(self, post_id):
return get_post(post_id)
class PostCommentResource(MethodResource):
@marshal_with(CommentSchema)
@use_kwargs(CommentSchema)
def post(self, post_id, commenter, comment):
return add_comment_to_post(post_id, commenter, comment)
app.add_url_rule('/posts', view_func=PostListResource.as_view('post_list'))
docs.register(PostListResource, endpoint='post_list')
app.add_url_rule('/posts/<int:post_id>',
view_func=PostResource.as_view('post'))
docs.register(PostResource, endpoint='post')
app.add_url_rule('/posts/<int:post_id>/comments',
view_func=PostCommentResource.as_view('post_comment'))
docs.register(PostCommentResource, endpoint='post_comment')
Exactly, if you provide the laundry list its easy to validate your assignment against it.
You submitted code which doesn't have things in my laundry list. Noticeably your db calls aren't surrounded by try/except. You have written no documentation. You didn't ship the code with git repo. No unit or functional test cases. I also expect these days one would use Python's typing library. Most of this helps in code maintainability. The fact that your assignment has none of this means you can't be hired to write production code ....
... See where this is going?
Despite you having written the code, someone with a different laundry list of quality checks can fail you.
> Exactly, if you provide the laundry list its easy to validate your assignment against it.
There is no laundry list. There is an expectation that a senior engineer writes codes like a senior engineer.
> You submitted code which doesn't have things in my laundry list. Noticeably your db calls aren't surrounded by try/except. You have written no documentation. You didn't ship the code with git repo. No unit or functional test cases. I also expect these days one would use Python's typing library. Most of this helps in code maintainability. The fact that your assignment has none of this means you can't be hired to write production code ....
Not sure if you are really this dense or playing dense - the point of the comment was to show that your assumption about api validation and sql injection being explicit requirements or taking too much time is ridiculous. It' simple that it can be written in a comment in about 10 minutes, not the "24 hours" or whatever you claim it is going to take.
The very fact that you think sql injection is an explicit requirement or takes work will be an instant deal breaker for any position with the possible exception of fresh grad positions.
> ... See where this is going?
Yes, I do. You are arguing reductio ad absurdum to hide the fact that the things which you claimed unreasonable are in fact routine, and your time estimates are off by order of 10.
>>There is an expectation that a senior engineer writes codes like a senior engineer.
You have no written list, but an imaginary checklist running in your brain about how a senior engineer writes code. Other engineers have theirs. I ran some of it and guess what, in that list absence of basic documentation, unit test cases, basic exception handling, code with types. Or even input validation for functions, like null checks is a no go.
Yet, if you submitted your feature complete project under a tough deadline to me, I'm not going to sit down and split hairs about absence of a favorite add-on feature of mine. That is what we are discussing here.
The code you posted in the comment above obviously doesn't have things like documentation, or validating function variables. Not even None checks. This obviously happens when some one attempts to write and submit code in minutes. When you write code this quickly, you focus on the exact feature demand at hand. Which in this case was SQL injection.
Other people got their feature set, in which several security add-on features would have been good to have but not in the time given.
>>You are arguing reductio ad absurdum to hide the fact that the things which you claimed unreasonable are in fact routine, and your time estimates are off by order of 10.
Oh obviously anyone who can do produce thousand(s) lines of code 24 hour project in 2.4 hours, is some totally different beast altogether.
There sure could exist such people who can produce >1000 lines of highly tested, security hardened code. I have yet to meet them though.
The closest I've seen is people who could write Lisp macros. But even those people wouldn't recommend writing code at the rate of 1000 lines per hour.
Welp. This is the point I checkout. You do you, but I have to ask. Do you have any production experience[1] and/or hiring experience? Because you have a very fundamental misunderstanding of both, and I find it very hard to believe that someone who has written even trivial applications would think that not having sql injection is an extra requirement or is going to take too much time, or anyone in hiring position is not going to politely terminate the interview after someone claims their assignment has an sql injection but that's because they didn't have much time and it wasn't explicitly asked for, or even consider calling someone for in-person eval when their assignment has an sql injection.
[1] There is a lot wrong with your "improvements". db calls aren't randomly placed in try/catch - that will be absurd. And the None checks aren't there because of something which you can very clearly see in the sample code but you also very clearly don't understand.
I keep repeating that this is not about SQL injection. You could be asked to write a command line app which doesn't even involve a SQL database. And yet there could a lot of such security or even other add-on's on which your code could be evaluated. We are literally discussing code quantity + time Vs Quality here.
>>Do you have any production experience
>>db calls aren't randomly placed in try/catch - that will be absurd.
Calls to databases go wrong all the time. Session objects expire, if you have cert based auths, they expire all the time. Especially if you have a largish microservices stack. Or you have locks on db objects, which you would run into. Or that network got flaky, or that just a certain type of resources like maxing out on db connections. Or that you are just trying to do write something to a database that is not allowed, like a duplicate primary key.
Never assume a database or any IO call for that matter will always go right.
Always check for every possible exception that could likely be thrown and handle it appropriately. Preferably each db interaction function should be atomic, and exception should be bubbled/raised/thrown to the application/feature main loop so that appropriate action like a retry or a roll back can be taken.
>>And the None checks aren't necessary because of something which you can very clearly see in the sample code but you also very clearly don't understand.
Pretty much any large codebase, that passes objects around should always do Null pointer checks. This is because several times resource heavy objects are initialized only on certain conditions, and if such objects are passed around they must be checked.
> I keep repeating that this is not about SQL injection.
Is that why you made that absurd claim about sql injection being an explicit requirement? And that weird figure of 24 hours for handling sql injection, and api validation?
> Never assume a database or any IO call for that matter will always go right.
I said "db calls aren't randomly placed in try/catch - that will be absurd". Because they will be handled at app level to return uniform error messages. Now I am sure you will go on pretending that when you said "db calls aren't in try/catch", what you meant was db calls can throw an exception and app will handle it.
> Pretty much any large codebase, that passes objects around should always do Null pointer checks. This is because several times resource heavy objects are initialized only on certain conditions, and if such objects are passed around they must be checked.
What did I say about None checks not necessary because of something which is visible in the code? What do you think those marshmallow schemas and use_kwargs is for?
A language with large standard library and tooling is awesome. But Racket still falls short on api wrappers for tools(message queues, zero mq, templates...) and services(payment gateways, google cloud or azure apis...). It's a chicken and egg problem. Unless a significant number of people start using it in production, Racket isn't going to have extensive libraries and unless it has the libraries to hit the ground running, a significant number of people won't try it.
> The thing that is the Special Sauce for Racket is it's macro system. You can build your own language for specific things easily or you can extend Racket with a library also much easier then the other 5-6 languages.
How are macros going to give me a better solution that the one which exists, is tested and have been used by others for some time? Besides, macros are a meme. What difference are macros going to make when wrapping a api? Can you show me an existing lisp/clojure wrapper which is more expressive than python/ruby?
The example you give doesn't have boilerplate so macro can't do more.
Macro can help for two things:
- reduce boilerplate
- add new function to your language (often specific and limited in context of use [racket's macro a suposedly composable]). Example: racket match, clojure.async.
I know what macros are and what macros can do. The parent poster made a comment that somehow macros can help overcome non-existence of wrappers in Racket. We both agree that macros won't help in this case, and my personal opinion is macros are a meme. They help some in very limited circumstances yet they are touted as a productivity multiplier. A pattern match over if-else doesn't really buy much. It's nicer, sure, but not by much.
The specific problem of wrapper around HTTP API have been resolved with WSDL (https://www.w3.org/TR/wsdl) assumming the use of WSDL the only thing a macro could do is equivalent of what an external program that generate a python file implementing the WSDL could do. I have written a php parser with the racket LLAR macro and it doesn't add more than an external tool like bison.
Reducing boilerplater could make your code less buggy (bugs you catch with your eyes) and could make the meaning of the code more clear.
Racket match is realy nice but it will shine if:
- You use a lot of immutable datasctructures.
- Explore shallow tree like data structures.
> and my personal opinion is macros are a meme
As far i has understand macro is already in use as Annotations for java.
In php, programmers developped complex frameworks that generate code (Symfony for instance) before running the user's code even if it isn't a macro per-se it share the same goal.
And i could have mention c++ template, so i don't think macro are a meme they already exists and there is a demand for it.
> assumming the use of WSDL the only thing a macro could do is equivalent of what an external program that generate a python file implementing the WSDL could do.
I am not assuming the use of WSDL and macros still don't do much.
> Reducing boilerplate could make your code less buggy (bugs you catch with your eyes) and could make the meaning of the code more clear.
Macros aren't required for reducing boilerplate and don't necessarily reduce boilerplate compared to a non-macro solution in an expressive language.
I read almost all of racket's documentation cover to cover and learnt Clojure about 5 years ago. There are a lot of good things to say about them but as far as expressiveness go, but I didn't found them anymore expressive than Ruby or Python.
> Racket match is realy nice but it will shine if:
> - You use a lot of immutable datasctructures.
> - Explore shallow tree like data structures.
The things you pointed out are non-macro things. I like match, especially when it's well integrated in the lang. viz f#. I just don't like the difference that being able to cook up your match using macros makes a huge difference when it comes to programming productivity.
> i don't think macro are a meme
You misunderstand my point. Code generation with or without macros is useful. That's not a meme. "Macros are a secret sauce" is a meme.
> Macros aren't required for reducing boilerplate and don't necessarily reduce boilerplate compared to a non-macro solution in an expressive language.
So i suspect you are thinking of ruby metaprogramming, in that case you have good and bad. With macro you can expand your code and have static tool reason about your code (IDE à la Éclipse). In the other hand in metra prog. you have all the info availlable at runtime and it is more easy to implement.
> I just don't like the difference that being able to cook up your match using macros makes a huge difference when it comes to programming productivity.
> It is probably an overstatement, if they have been useless for you (and me) doesn't mean they are.
You are conflating "useless" with "secret sauce". I didn't claim they are useless. I said macros are a meme and are useful in very limited circumstances.
I have developed a very nice Lisp dialect from the ground up, in which macros do all these things:
* completely implement the system of "syntactic places": the ability to mutate variables, mutable slots of various kinds on various objects, and user-defined such things. The only API underneath consist of ad hoc functions to update specific kinds of places.
* implement the syntax of the object system: structure defining via defstruct, instantiating objects with new and so on: over top of an API consisting of functions to manipulate the object system.
* various control structures.
* the op macro for currying / partial application.
* the FFI language for defining foreign types, and its operators like typedef, sizeof and offsetof.
* the awk macro: a fully-loaded, "Lispified" version of the Awk language.
* generator-like programming interface (featuring yield with bi-directional communication of values) implemented over top of delimited continuation primitives.
Many more. Macros provide a catalyst for language research. New syntax can be added to existing syntax without any conflict, and without having to muck around with a parser. The new syntax doesn't even have to be loaded into memory if it's not being used.
"Macros don't do much; I don't need need to write macros" ignores all the macros that have been already provided and the benefit they bring. You can't be using existing macros left and right while claiming that they are not all that necessary.
You may feel that way when using a language that has no macros. But the syntax of such a language is effectively a macro expander. A Yacc rule (or what have you) which matches some symbols on the left and produces a piece of AST in its action body is effectively a macro. Someone else wrote that syntax and you benefit from it, just like you benefit from existing macros in a Lisp. But that syntax hinders development of that language; it is ultimately detrimental to that language. Because new versions of the language struggle with the integration of new syntax, they create backward-compatibility wrinkles.
With macros, if I have some piece of code that uses syntax available only in the latest and greatest version of the language (not what I'm using in production), I may be able to just write the macro to simulate the feature well enough to get the code working. Code relying on hard-coded new syntax has to be rewritten not to exhibit a syntax error with the older language.
The ability to define macros can really help work around bugs in existing macros. If hard-coded syntax is broken, all you can do is code around it with different syntax. If a macro is broken, you can write a macro just like it (only with a different name) or perhaps even redefine it. The code doesn't have to change at all. Eventually when upstream fixes the bug, the workaround is removed and that is that.
Since macros are ordinary identifiers, they can be namespaced. Just because you introduce a new control construct called wonk doesn't mean that wonk is now a reserved token in a syntax, which breaks everyone who used wonk as a variable name. Syntax-in-a-package (rather than in a global parser) is awesome!
If Python had macros, Python 2 to 3 migration would be a non-issue. It wouldn't be a topic of discussion that non-Python-programmers know about.
> Someone else wrote that syntax and you benefit from it, just like you benefit from existing macros in a Lisp.
Are you following the discussion? The whole discussion arose from somehow macros make up for non-existence of libraries in Racket. Someone else wrote all those libraries for popular languages and I benefit from those existing libraries. Macros do fuck all if I have to wrap them myself. And even if I have to, most of the times it will be way simpler to wrap it in Python/Ruby.
You wrote a novella on your hypothetical macro use cases. I wrote I know what macros are. I don't know why you are throwing that at me.
> If Python had macros, Python 2 to 3 migration would be a non-issue. It wouldn't be a topic of discussion that non-Python-programmers know about.
This is what I mean when I say macros are a meme.
No, it won't have helped, at all. The changes in python 3 break the existing python 2 code.
> For example, this no longer works: k = d.keys(); k.sort(). Use k = sorted(d) instead (this works in Python 2.5 too and is just as efficient).
> The ordering comparison operators (<, <=, >=, >) raise a TypeError exception when the operands don’t have a meaningful natural ordering
> builtin.sorted() and list.sort() no longer accept the cmp argument providing a comparison function.
> The biggest difference with the 2.x situation is that any attempt to mix text and data in Python 3.0 raises TypeError, whereas if you were to mix Unicode and 8-bit strings in Python 2.x, it would work if the 8-bit string happened to contain only 7-bit (ASCII) bytes, but you would get UnicodeDecodeError if it contained non-ASCII values.
> No, it won't have helped, at all. The changes in python 3 break the existing python 2 code.
In a Lisp setting, the 2 code could be supported in an environment where it is not broken, in the same image in which 2 code is running. It could be redirected to use library symbols from a 2 package. E.g. if the hypothetical floop syntax changed there could be a ver2:floop and ver3:floop.
If necessary, the entire 2 implementation could be separately provided via this backward compatibility mechanism. Yet, 2 and 3 code could be freely mixed even in the same function. E.g. an instance of ver2:floop could nest inside ver3:floop.
> if the hypothetical floop syntax changed there could be a ver2:floop and ver3:floop.
dict.keys() returned a list earlier, now it returns a "view". dict already had keys() and iterkeys(). Is that what you were referring to by your ver2:floop and ver3:floop? They changed keys() to act essentially like iterkeys() and removed iterkeys() because per them, this is the correct behavior.
Most changes in python 3 won't be helped by macros. Macros would have helped if they were adding say pattern match. But even then, it doesn't really matter much. If python itself is adding pattern match, they can write it in C, or python, or write a macro(if python had it) - it would have been all the same to me.
I am not saying macros aren't useful. I am saying macros are useful in limited circumstances and existence of macros won't have done anything for python 2 to 3 migration.
You are just deflecting now. You made the claim that somehow macros would have made the python 2 to 3 migration easy. You are yet to demonstrate which of the migration issues would have been solved by macros.
dict.keys() returning something different from what it used to isn't a syntactic change; it's a change in function behavior. Since macros handle syntax, they aren't applicable to a function semantics change.
What we might do here is to use two different keys symbols in different packages. We can have a ver2:keys and ver3:keys and control which of these dict.keys() uses in some scope. But that's not macros.
The point is that with macros, we can do the same thing with the syntax of the language; it's a library feature that we can subject to versioning. Old syntax can be supported side by side with new syntax. So then since we have a way to have old syntax and old API semantics, which is pretty much everything, we can have a nice migration path.
> dict.keys() returning something different from what it used to isn't a syntactic change; it's a change in function behavior. Since macros handle syntax, they aren't applicable to a function semantics change.
Now you are telling me something I told you in the first place.
> What we might do here is to use two different keys symbols in different packages. We can have a ver2:keys and ver3:keys and control which of these dict.keys() uses in some scope. But that's not macros.
Right. So like I said, macros won't have helped, at all.
> Old syntax can be supported side by side with new syntax.
Creating a Frankenstein's monster was never the goal. And besides, they already had tools for code which can run both on 2 and 3.
I don't think the point was necessarily that you can always do better with lisp (with or without macros). A best case solution, regardless of language, can't be improved by definition.
The point is that you can adapt lisp to an equivalent best case solution. And if you like to program with lisp, that's a win. If you don't like lisp, then it doesn't matter.
I don't have a particular affinity towards or against insta influencers or youtube stars. I just find the comments amusing.
"I am so much better than insta influencers because, uh, I have a job? I don't seek validation from strangers? I am not sure but I sure know that they are the downfall of the humanity"
I think generally yes, we as a society look down on those who are starved enough for attention and validation to constantly need it from strangers. That's pretty much how society has always been.
> If our best and brightest young children become internet celebrities because it made good sense, then there won't be anyone to keep the gears grinding.
So do you also support not educating a vast majority of children because if everyone aspires to be a white collar worker, where will we get our janitors and garbage men from.
> Think of how that forms the development of a young child.
It depends.
Option 1:
"Hey buddy. So you want to be a youtube star. Which ones you like? The funny ones? The lifters? The fashion vloggers? It's actually a lot of work. You will need a script, a cameraman, a director, actors etc. And all said and done, for every youtube star, there are tens of thousands who just toil in obscurity. But that's a risk which comes with a lot of life's decisions and you can decide later on if you really want to do it or if you want to do it part time.
Back to the production process. It's not very different from what we do in our school's theater except that there is a massive potential increase in your reach. Why don't you try coming up with a concept and I can walk you through the iterations it takes for the final product. We can even try to schedule a screening for the class and put it on youtube."
Option 2:
"Youtube star? SMH. What has become of today's generation?"
I share this sentiment. I dump almost daily photos on whatsapp statuses. I won't do it on insta or fb(except on their analogous stories/status feature). I like posting updates but since I don't like when people clutter my wall with a lot of updates, I don't do it to others. The only people who see my updates are people who explicitly click on it to see it.
There are two usages to the word "vanity." The one you're referring to has more to do with dignity (the desire to be respected by everybody.)
The property under scrutiny by the parent poster, though, is (I think) more like "narcissism"—the desire to be perceived as the best person ever by as many people as possible.
The desire for dignity is universal; whereas narcissism is a (rather uncommon) personality flaw.
> dignity (the desire to be respected by everybody)
Weird. I thought dignity is self-respect(not respect from others).
So do you have a list of what earns you dignity vs what is narcissism? Like covering your gut in loose clothing is fine but god forbid you post your abs on insta where only people who see it are people who willingly followed you to see it and the people who went on to explore tab to see it and then jumped on hn to whine about it.
> the desire to be perceived as the best person ever by as many people as possible.
I don't know - sounds like ambition to me.
Insta has given aspiring models a mostly democratic platform. You don't have to be a size zero or white or what have you. Build your reach and you are a model. Same goes for youtube - it has vastly empowered indie content creators. Of course there are millions of people who post their photos seeking validation from friends and strangers but what of it? Humans have been seeking validation from strangers since time immemorial otherwise why have lavish weddings or expensive wedding rings or expensive cars...
IMO people complaining over overt insta sharing are self-righteous whiners. I see it on the same level as being outraged over Rebecca Black. Don't like it, don't seek it. You think you are better than others? Don't tell, go actually be better.
> So do you have a list of what earns you dignity vs what is narcissism? Like covering your gut in loose clothing is fine but
but what has it to do with dignity? And why would anyone need a "list"?
> Don't like it, don't seek it.
I can be aware of something and have an opinion about it without engaging in it. And I surely do not need your permission for that, and calling anything negative you don't like "complaining" without considering your own complaints as just silly.
> Build your reach and you are a model. Same goes for youtube - it has vastly empowered indie content creators.
Don't even need to go into models, they are there to sell product, but I'll just say that calling people "content creators" is like calling someone who is attacked as maybe not being such an earnest author a "page filler". That's the low we sunk to, that's already normalized. "Creating content" has as much "value" as people give it in form of "attention". The capitalism of the mind, the destruction of all information. Work 50 years, rob someone who worked 50 years, you can buy the exact same thing... get X views doing A, or X views doing B, it's still just X views.
I guess I should make a youtube video about it, then it'd be valid even if it called out other youtubers? Help me out here, since apparently typing a comment in a text box is not creating content if it rubs you the wrong way.
> Humans have been seeking validation from strangers since time immemorial
Yes, but that doesn't make it less dysfunctional, and others have been calling them out for being fucked in the head for just as long. The idea kinda is that you do not constantly "seek validation", but you already more or less have that figured out after a while, and then it's more about responsibilities and challenges and things you enjoy. And yes, it's fun to be liked. Just like it's fun to like people. But if validation and self-esteem are some kind of elusive fix you constantly have to seek, you're doing it wrong.
Last but not least: You're basically saying, if you found a bug, don't talk about it, fix your own copy and just use that. Fuck that. What would you know about ambition? What if my being better includes speaking my mind? Riddle me that.
> but what has it to do with dignity? And why would anyone need a "list"?
Conversations have context, you know. Parent poster mentioned dignity being different. Did you not read the or are you intentionally clipping it.
> "Creating content" has as much "value" as people give it in form of "attention"
Is..is that supposed to be an insult or some deep insight you stumbled onto? I don't understand why you are stating the obvious with such conviction and quotes.
> Work 50 years, rob someone who worked 50 years, you can buy the exact same thing... get X views doing A, or X views doing B, it's still just X views.
You are kinda going off the rails here buddy.
> I guess I should make a youtube video about it, then it'd be valid even if it called out other youtubers? Help me out here, since apparently typing a comment in a text box is not creating content if it rubs you the wrong way.
Cool. Now you are making up arguments on my behalf and posting your retorts.
> You're basically saying, if you found a bug, don't talk about it, fix your own copy and just use that.
That doesn't even come close to being an analogy.
> What would you know about ambition?
I can explain that to you. Or you can go back and read the conversation again, slowly.
> What if my being better includes speaking my mind? Riddle me that.
Maybe try to be actually ambitious rather than being content with raging over people doing better than you.
> Conversations have context, you know. Parent poster mentioned dignity being different. Did you not read the or are you intentionally clipping it.
No, I got that. And then I asked, why would one need a "list of activities" to make that point? I don't see how that would work, seeing how those activities also have contexts and motivations which matter. It's like "taking bread from a place and putting it somewhere else" can be various things like making breakfast, stealing food, giving food, playing with food.
> You are kinda going off the rails here buddy.
Off what rails? Your comment was an own goal, I'm just beating a dead horse.
> Maybe try to be actually ambitious rather than being content with raging over people doing better than you.
It's more mocking people who I consider lame. Which brings us back to your projected "Now you are making up arguments on my behalf and posting your retorts." haha.
> And then I asked, why would one need a "list of activities" to make that point? I don't see how that would work, seeing how those activities also have contexts and motivations which matter.
All right. I will give it a last try. You would need a "list" if you are the one making a point that hiding your gut is just dignity while posting your abs online is narcissism. I was pointing out to parent poster that this point is not conducive as your are defining dignity and narcissism to suit your point of view. I don't understand how you missed it when it's written verbatim in the comment you replied to.
> Your comment was an own goal, I'm just beating a dead horse.
And here we go again. You think of something and put it down in your comment irrespective of context. What dead horse are you beating and why does this phrase make an appearance out of blue here?
> It's more mocking people who I consider lame.
At least we have the same agenda here. I too enjoy mocking bottom feeders who write diatribes out of their jealousy for people leading a better and more fulfilled lives than them.
> Which brings us back to your projected "Now you are making up arguments on my behalf and posting your retorts." haha.
Again, I am sure you think you have a point here and I am supposed to have an epiphany when I grok it, but honestly, all I see is random sentences chained together. I once saw a video of some pastor who brought a rock to a talk show as an irrefutable proof against evolution. I am kinda feeling the same as the talk host felt.
Cool man. You do you. Continue "caring for others" by, uh, posting comments on hn I suppose, and "being better", uh, again by posting comments on hn.
Doesn't matter. Whether the body can extract calories out of it doesn't change the definition of calorie and a calorie is still a calorie.
"But some foods are more filling and satiating than others despite the calories being the same"
Still doesn't matter. How does how long the body takes to process calories out of food affect "a calorie is a calorie".
You must already know this. I might have been a bit pedagogical but that's because "a calorie is a calorie" is false is one of my pet peeves.
More to the point:
> then we need to be able to explain why two people eating the same amount of calories per day, but one eating a high fat, low carb diet, and the other a low fat high carb diet see starkly different outcomes.
Studies please. Especially for "starkly different outcomes". I can copy pasta the famous /r/fitness link dump which is posted every time keto comes up but I will wait for you to find me some studies supporting your argument first.
> All things equal except the composition of their diet, the person on the HF diet will stay lean and feel consistently satiated, while the LF person will put on more fat and feel hungry far more frequently than the HF.
So I can feed 5000 kcal/day to a 5 feet girl and she will stay lean as long as it's olive oil shots?
> IMO, the claim that all calories are created equally is the most damaging "science" that's been put forth as common knowledge about dieting.
But all calories are equal, by definition. Some people do well on a high fat/high protein diet, some don't. You want to lose weight, burn calories(eat less, move more) above your tdee. You want to gain weight, give your body more calories than it burns. As annoying as hearing this may sound(it isn't annoying to me but for argument's sake), that's all there is to it. People have lost weight and maintained lean mass on all sorts of shitty diets. If high fat diet works for you, superb. But it's not a panacea and the science is no where as clear cut as you make it out to be. In fact, keeping protein constant, a high fat and high carb diet had the same results.
Yes! To reiterate: the backlash against calorie counting into not taking calories into account at all is just as damaging.
Certain foods help satiate better than others at lesser calories -- which is why some people find that eating 1500 calories of high fat and protein foods to be much easier to live with than eating 1500 carb heavy calories.
IMO, that's one of the big draw of keto. It's not that you can magically eat 5000 calories of cheese and meat and lose weight. It's that you can eat a caloric amount at a deficit and still feel energetic and full and like you didn't miss out on anything.
No, not in 24 hours. In about 2 hours. The laundry list of things - api validation, error handling, db migrations, good naming - it's pretty routine. A person writing production apis will have no trouble integrating all of it in a very short period of time. This is after all what we do everyday. If a candidate thinks not having sql injection in the code is an explicit requirement or is going to take a lot of time, then that is not the person for the job.
Here is a pretty simple flask implementation of your laundry list - api validation, db migration, no sql injections, no n+1 queries, good naming, swagger ui...