|
If you want to make your script even more 1337, you could get automatic indexing by using console.table[^] instead.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: make your script even more 1337,
You are actually really right on that. Big miss by me. 
I will learn from this and do better next time though. 
|
|
|
|
|
|
I asked because the Google API docs are pitifully lacking. For example, look at this:
https://developers.google.com/people/v1/contacts
There's 'peopleService' in the code, yet no mention of what is is. I searched all over and finally found this, which is the best top to bottom example I've found: Accessing the People API from C# / .NET
Their docs are typical. Show a few lines that mention the topic, but not enough to make sense of it.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: I asked because the Google API docs are pitifully lacking.
Yeah, I understand & agree 100%. I wasn't trying to be a smart-*ss (altho herself says it comes naturally for me) was just not sure which API you'd be interested in.
I also couldn't believe how many there are -- even for Google.
Kevin Marois wrote: Their docs are typical. Show a few lines that mention the topic, but not enough to make sense of it.
That does seem to be the Dev-Way. 
Here's my fav meme (image) that shows devs' relation to docs[^].
|
|
|
|
|
Looks about right 
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
raddevus wrote: I wasn't trying to be a smart-*ss
Are you sure of that?
raddevus wrote: (altho herself says it comes naturally for me)
women are always right... you know 
 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
You should publish that script as the Google API API.
However you might want to fix it first. I'm currently a registered user of just 5 Google APIs, and not a single one of them appears in your list. According to my "Enabled APIs" page, I'm using:
* Geocoding API
* Maps Javascript API
* Directions API
* Distance Matrix API
* Maps Embed API
My guess is that if these aren't in your list, then probably dozens - if not hundreds of others - aren't either. 
|
|
|
|
|
DerekT-P wrote: probably dozens - if not hundreds of others - aren't either.
Uh, the list is from Google's API Explorer.
I cannot update the Google API explorer.
Please submit your request to the correct office. Thanks yous.
|
|
|
|
|
LOL - I wasn't having a go at your list. Just observing that the list you generated is the tip of an iceberg. Seems even Google's own API explorer has some major shortcomings - heaven help the rest of us! 
|
|
|
|
|
Google's products and APIs change so frequently, any book would be out of date and obsolete before the author had finished writing the introduction. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
Now that some time has past ...
When I say use a browser and not an app, it's not because I'm against the "owner" of the app; it's their having direct access to my device, its sensor, GPS and its data.
Recent events and what are claimed to be new "features" (involving "your" data) should make this somewhat more clear.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
In the case of my iphone, I DON'T WANT all those 157 stinking, overly specialized, half the time flakey, way too often wanting to update, apps on my phone!
|
|
|
|
|
Yup. The older and (hopefully) wiser you get, you realize apps designed to steal your time and attention are very expensive in terms of your life... even if they were free to download.
Jeremy Falcon
|
|
|
|
|
Yeah, what Craig said.
I install very few "apps", I definitely prefer to use a browser when possible. But for me it's not about the data either; it more about experience and convenience. For example, when viewing Instagram I can use "open link in a new tab" (or whatever) and have multiple tabs open to the same site -- as far as I can tell, the "app" doesn't allow that.
|
|
|
|
|
So, I saw this infoworld blog pass by, discussing how full-stack is a fallacy in and of itself.
The take away being that a good team consists of specialized people, backend and frontend.
Not people that "pretend to know it all" and "take twice as long to do anything".
This notion has ruffled my feathers the wrong way, for a couple of major reasons.
- I run a very small team, about half the size of a typical team within our company.
- Every team member is full-stack, from junior to senior.
- Every year, for the past 3 years, we are attributed at least 50% of the entire value proposition created each year.
We are not specifically gifted, we don't pretend to know it all, and we regularly make mistakes.
Even still, our delivered quality is regarded as exemplary, and by far, we innovate, iterate and improve the most, relative to the other teams.
So, what's going on here?
Why do we succeed, while teams with dedicated backends and frontends seemingly require more time and coordination to succeed, in the same company?
Ironically, for exactly the same reasons as written in that blog post.
We work together and we specialize.
The key being, we don't specialize on arbitrary lines.
We specialize in our understanding of the code.
Because all of us can do the same tasks, we are regularly confronted with our strengths and weaknesses, and the entire team can give feedback and advice to each other, on everything.
Instead of artificially limiting the scope of tasks each developers gets assigned, we can and do collaborate on everything.
Instead of creating an artificial wall where ownerships gets handed over, each developer can complete a feature or bug from start to finish.
Instead of creating little islands of specialized knowledge, where only 1 or 2 people can ask critical questions, everyone within the team can ask critical question about anything they don't fully understand.
And we don't fully understand very often, and ask a lot of dumb questions.. which is very good when it comes to quality!
The end result is that all of our solutions are easy to understand, have a single owner, and are never over-engineered.
Yes, teamwork is essential. But having a team that actually works together is a prerequisite for that!
And as a side bonus:
- we caution each other to not take on to much work at once, because we can assess each others workloads
- we actually feel like a team of equals, regardless of personal experience
- the personal gratification we get when ownership is respected, and gets critical acclaim by clients, results in an astronomically high eNPS
|
|
|
|
|
Well written Kate-X257. It sounds like you are a member of a great team. That doesn't happen for everyone.
Congratulations and best wishes!
Craig Robbins
|
|
|
|
|
Ditto. Kate said it quite well.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Thank you, I made it myself. 
|
|
|
|
|
I'm with you on this. Used to manage three small teams until recently (now I'm a single warrior), of 3, 6 and 4 developers on three different continents. You have to use effectively all available resources, which is next to impossible with specialized developers like "backend", "frontend/presentation" and "DB developers". You grab the first available developer and work with him/her on an urgent task. I would prefer a specialization based on areas of work and/or business segments for long term projects, rather than specialization in technologies.
And this goes to all fields, not only .net fill-stack developers. Imagine embedded systems programmer with absent knowledge in computer architectures (or electronics). Not cool. Not cool at all.
There is only one Vera Farmiga and Salma Hayek is her prophet!
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
Once there were programmers.
Then there were analysts; to guide the programmers.
Then to simplify things, they added programmer-analysts.
When the software got too "techie", the programmers split into systems and application programmers ... who needed their own supervisors, directors, and VP's.
Then the system software got too "fat", so there came database analysts, programmers, and administrators.
Then the big machines got smaller and ...
It's all just a question of scale.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Sure, after 40 years of developing, one can really learn backend and frontend well. But full-stack is a term that's abused and overused way too much. What it's come to mean colloquially is "I do some backend and well I've seen a few bits of JavaScript. What's CSS again?"
The idea a junior or even a mid can be full stack is an outdated notion. The frontend has evolved tremendously. Even outside of that, I can't even begin to tell you how many "full-stack" developers still don't know CSS even. They all swear they do because they've seen a div. But nope. They cannot beat a real expert that dedicates their time to it.
The problem is, a lot of developers have no respect for the frontend. And in their mind they think they can do it all. Nothing could be further from the truth.
Personally, I'd never hire someone who claim to knew it all. Even after 30 years of development and being able to hold my own on the backend, I still specialize in the frontend and don't know it all on the backend. I'm good, but I won't beat someone who dedicates all their time to it. Not to mention, you take two seconds to sneeze and even the frontend changes.
This isn't the 60s... the industry has evolved.
Jeremy Falcon
|
|
|
|
|
It's a good counter-point.
A junior full-stack, for me, is a junior that can be effective in all parts of the stack, and takes ownership of the work until it's done. I have one, and every time he doesn't fully grasp something, he asks the most experienced full-stacks within the company on how they would approach the problem, and he openly discusses complex issues with other front-end specialized people. He collaborates effectively.
I strongly believe front-end specialists are valuable and needed within every company.
I just don't agree that a full-stack team cannot be effective.
|
|
|
|
|
Also, the business priority for smaller companies cater to the need of not having specialists in order to save money. But that doesn't mean a generalist actually knows what they're doing or is better at their job.
Jeremy Falcon
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
