|
What I really enjoy is big robust APIs that sporadically return loving 500 errors. AdWords I'm looking at you God dammit you're fricken Google can you please fix your own goddamn poo poo
|
#
?
Oct 2, 2017 00:29
|
|
|
|
| # ? May 16, 2024 14:42 |
|
|
So. Flickr. Flickr has a method called "flickr.photos.geo.forLocation" which you would think would be for getting photos based on a geographical location. Hmm, maybe I'm wrong. What does the documentation say?quote:Return a list of photos for the calling user at a specific latitude, longitude and accuracy quote:lat (Required) A random post on Flickr from 6 years ago that I just stumbled upon quote:flickr.photos.geo.forLocation is very, very specific, and will only return photos with an exact match on the latitude and longitude. You probably want to use flickr.photos.search and put a radius value in along with the lat, long and accuracy to get something like the result you see on the right.  I DIDN'T EVEN NEED TO loving USE OAUTH TO BEGIN WITH. I've spent the past week learning and playing around with it and struggling terribly AND I DIDN'T NEED OAUTH. What a weekend. I've made 1 step forward and 3 steps back with my personal project.
|
|
#
?
Oct 2, 2017 00:49
|
|
|
On the bright side, you note have oAuth experience!
|
|
#
?
Oct 2, 2017 01:40
|
|
|
Yeah, despite the fact that its way too fuckin complicated, oauth is a good thing to know.
|
|
#
?
Oct 2, 2017 16:16
|
|
|
Why doesn't Google Chrome show the spinner while iframes are loading anymore? It seems like a very recent change. Only thing I could find about it was this post: https://stackoverflow.com/questions/46361253/loading-webpages-in-iframe-dont-start-spinning-circle
|
|
#
?
Oct 2, 2017 22:41
|
|
|
Data Graham posted:What I really enjoy is big robust APIs that sporadically return loving 500 errors. AdWords I'm looking at you Man don't even talk to me about AdWords. The supposed bread and butter of Google's entire massive empire and the API is unusable. I spent at least a year of my life trying to automate a big Adwords related thing. I can't remember which random deeply nested endpoint it was expects a value in 1 millionth of a penny. Do that math wrong, use 0.1 millionth of a penny like an idiot, and get charged $ out the bum.
|
|
#
?
Oct 2, 2017 23:57
|
|
|
MrMoo posted:Many projects yield the same generic error on authentication due to "security reasons", i.e. being able to use the feedback to improve an attack. It's a wonderfully lame excuse. Also a totally valid one, unfortunately. I used to work on Guild Wars 2 and we had to keep making our APIs/sites return more and more generic errors to avoid information leaking attacks. It sucked, but that's what happens. A few poo poo-heads ruin things for everyone.
|
|
#
?
Oct 3, 2017 07:17
|
|
|
Nolgthorn posted:Man don't even talk to me about AdWords. The supposed bread and butter of Google's entire massive empire and the API is unusable. I spent at least a year of my life trying to automate a big Adwords related thing. I have yet to use a Google API that wasn't terrible in some way.
|
|
#
?
Oct 3, 2017 16:52
|
|
|
I really liked the Google Maps API, I used that recently. Works pretty well but the radius stuff is a bit suspect. No way to get visible results, some math is required and then you have to loop through the results to see if they're really on the screen. Also the radius is more like an oval.
|
|
#
?
Oct 3, 2017 17:48
|
|
|
Wait a minute that was the Yelp api.
|
|
#
?
Oct 3, 2017 17:55
|
|
|
.
melon cat fucked around with this message at 06:48 on Mar 16, 2019 |
|
#
?
Oct 5, 2017 03:23
|
|
|
Look in to squarespace. If it has the features you want, it's really good and will save you a ton of administration hassle.
|
|
#
?
Oct 5, 2017 06:11
|
|
|
Thermopyle posted:Look in to squarespace. If it has the features you want, it's really good and will save you a ton of administration hassle. Why can't I just have it all.
|
|
#
?
Oct 5, 2017 16:11
|
|
|
melon cat posted:I've considered SquareSpace, but I really don't like the fact that I have to use their pre-bundled Hosting. Nothing against Tucows or anything, but I already purchased and own my own Hosting. Consider if you really need your own hosting. A lot of the time people just feel like they have to have it but can't really articulate a good reason why and then realize they don't really need it. (you may need it, I don't know)
|
|
#
?
Oct 5, 2017 16:17
|
|
|
It's not good, but GoDaddy Website Builder is very straightforward if your hosting is already there. I've heard a lot of talk about Pico as a lightweight CMS but haven't tried it. Grav looks similar but might be more bloated based on a surface scan. I've used Bolt but am not really a fan.
|
|
#
?
Oct 5, 2017 18:05
|
|
|
Scaramouche posted:It's not good, but GoDaddy Website Builder is very straightforward if your hosting is already there.  Thermopyle posted:Consider if you really need your own hosting. A lot of the time people just feel like they have to have it but can't really articulate a good reason why and then realize they don't really need it. But thank you for suggesting Squarespace. I'll take a closer look at their templates and pricing. 
melon cat fucked around with this message at 18:09 on Oct 5, 2017 |
|
#
?
Oct 5, 2017 18:05
|
|
|
melon cat posted:I've always heard that GoDaddy is a total pain to deal with, though. Not sure if that's still the case. They seemed to have scared off a lot of people in recent years. Never heard of Pico, so you have... Pico'd my interest. Yeah I wouldn't switch to GoDaddy just for that feature, just mentioning it in case the hosting you had already acquired was with them.
|
|
#
?
Oct 5, 2017 18:10
|
|
|
I have an HTML canvas that I'm using for image uploads and the final step is to use canvas.toDataURL('image/jpeg', QUALITY) to prepare the image to post. The QUALITY variable is currently a constant but I'd like to have it change according to the image uploaded. My first thought is to do some sort of relationship between kilobytes per pixel of the original image and the value of QUALITY. Does this make sense? I feel like that might not be enough information to decide wether an image can be reduced in quality or not.
|
|
#
?
Oct 10, 2017 17:20
|
|
|
It's a bit bike shedding. You're almost at the point of converting to image/png then running a web assembly transpiled version of pngcrush before uploading to save a few bytes. Maybe ok in really slow networks but the slower lead time would be more annoying than slow upload time. If you want to reduce size with a lossy protocol then image/webp would be the best option. You also have the option of webassembly version of convert to convert a png to webp in a web worker for unsupported clients.
|
|
#
?
Oct 10, 2017 17:57
|
|
|
melon cat posted:I'm putting together a new website for my fledgling video production company. I used to use Wordpress because I like the WP Dashboard and wide array of themes, but hate the annoying trend of all new WP themes incorporating so much bloat and fullscreen parallax scrolling (why is this even a thing?). So I'm looking for a lightweight alternative CMS to Wordpress that's easy to launch and has blogging functionality. There are definitely WP themes out there without all that bloat (I despise fullscreen parallax as well), or if you're willing to spend a little more time you could take something like Bones or Underscores or Sage (might be overkill) and make yourself a custom theme with just the basics. Something else to consider would be using WordPress for the backend, and the WordPress REST API to make the frontend in whatever you like, even just some HTML/CSS/JS files. I've been doing this for a few people who also like the WP Dashboard for data management and it's worked out very well so far. Unrelated question: I'm doing some minor front-end things in jQuery, really simple stuff like changing what image is loaded into a modal window when different images are clicked on. Is there any point to doing this in vanilla JS as opposed to jQuery i.e. would it be worth it to remove jQuery from the site entirely for performance?
|
|
#
?
Oct 11, 2017 20:19
|
|
|
jQuery is still a great tool for trivial things like your use case. It's 85k minified uncompressed and the call overhead is tiny. Don't worry about performance until you can actually measure a problem. Use it as a tool to increase your performance. If you can dev it faster using jQuery, then use jQuery. That said, make sure you actually know how you'd go about doing the same tasks in plain old regular vanilla JS. Remember, jQuery is from an age where there were horrifyingly wild inconsistencies in how browsers treated basic things like the DOM and events. We no longer have that problem and there's nothing that jQuery does that you can't do safely by hand in every modern browser.
|
|
#
?
Oct 11, 2017 20:50
|
|
|
my bony fealty posted:Unrelated question: I'm doing some minor front-end things in jQuery, really simple stuff like changing what image is loaded into a modal window when different images are clicked on. Is there any point to doing this in vanilla JS as opposed to jQuery i.e. would it be worth it to remove jQuery from the site entirely for performance? If you're loading jQ from a CDN it's probably a wash. The images you're tossing around probably use more bandwidth and aren't going to be cached already when your users hit the site.
|
|
#
?
Oct 11, 2017 20:51
|
|
|
McGlockenshire posted:That said, make sure you actually know how you'd go about doing the same tasks in plain old regular vanilla JS. Yeah, there's lots of people out there who don't really know javascript...they know jQuery. I can't really say that's wrong, because it works for them (or some portion of them), but I wouldn't want to be in that situation.
|
|
#
?
Oct 11, 2017 21:47
|
|
|
Thanks for the tips and yeah, I am a person who found myself going at one point "I know jQuery well but I wouldn't know how to do this in JS" so I went back and bought a big ol JS book and corrected that. I know now that relying on jQuery alone was a Very Bad Idea because it impacted my understanding of JS coding in general, e.g. 'why do I need to learn how to use functions properly, I can just manipulate the DOM directly everytime  '
|
|
#
?
Oct 11, 2017 22:09
|
|
|
Thermopyle posted:Yeah, there's lots of people out there who don't really know javascript...they know jQuery. at work we have a coding test for interview candidates. Some questions involve writing some functionality in jQuery. The supposed hard part is to turn the jQuery into vanilla JS. This test is super outdated and hasn't been changed in like 5 years.
|
|
#
?
Oct 12, 2017 01:44
|
|
|
Grump posted:at work we have a coding test for interview candidates. The hard part of that test is trying to figure out what different jQuery functions used to do.
|
|
#
?
Oct 12, 2017 07:25
|
|
|
Nolgthorn posted:The hard part of that test is trying to figure out what different jQuery functions used to do. Yeah, I'd fail the "do it w/ jQuery" part because it's been so long.
|
|
#
?
Oct 12, 2017 15:50
|
|
|
Lumpy posted:Yeah, I'd fail the "do it w/ jQuery" part because it's been so long. I'd take JavaScript code:
|
|
#
?
Oct 12, 2017 16:16
|
|
|
Lumpy posted:Yeah, I'd fail the "do it w/ jQuery" part because it's been so long. Doing it with jQuery is easy, you just pretend jQuery in't on the page.
|
|
#
?
Oct 12, 2017 21:03
|
|
|
I have a question about backend programming because I'm not a backend programmer and I'm not super clear on a lot of concepts. I get on the front-end you can run HTTP requests to get data from a server and you never want to write to a server because all the code is viewable to the user. In back end languages like PHP, for example. do SQL queries take the place of HTTP requests. Is there a point to using both? What's a use case where you would need to use an HTTP request on the back end to get data from a server or write to a server?
|
|
#
?
Oct 13, 2017 00:30
|
|
|
Grump posted:What's a use case where you would need to use an HTTP request on the back end to get data from a server or write to a server? HTTP is used in pretty much every web API out there. If you want to use any of Amazon's hundreds of web services, you're using HTTP to do it. For a specific example, if you wanted to send a file to a S3 bucket, the application would poke and prod at the S3 API over HTTP to do so. quote:In back end languages like PHP, for example. do SQL queries take the place of HTTP requests Literally, no. Figuratively, yes. Maybe you can re-explain your question, because I'm not sure why you'd ask this question this way...
|
|
#
?
Oct 13, 2017 01:14
|
|
|
Grump posted:I have a question about backend programming because I'm not a backend programmer and I'm not super clear on a lot of concepts. I'm not really sure what "never want to write to a server because all the code is viewable to the user" means. You're "writing" to a server when you POST a form or JSON or whatever. There's nothing magical about the backend, it's just programming. Generally a server works like this when you send a request to it. 1. Some server like Apache or nginx gets a HTTP request from a browser, an app, a script, whatever. 2. It has rules on what to do with requests to different domains and paths. 3. It passes the request to your app which gets an object with info about the request. The HTTP method, the body of the request, headers, the path requested, etc. 4. Your app uses that info to decide what code to run. 5. Your code then looks up some data in a database, or sends a request over HTTP to some other REST API, or does some calculations, or saves the file in the HTTP request to disk, or closes your garage door, or whatever you write the code to do. 6. It sends a response back to the client with whatever content and HTTP status and headers you desire. The latency of your request (how long it takes from when you initiate the request to when you get data back from the server) is usually determined by whatever your code is doing in step #5. It's not actually super complicated to write code to do all this from scratch, but using a framework like Django or Rails or ASP.NET or whatever makes it a much more sane process that you can actually reason about and maintain.
|
|
#
?
Oct 13, 2017 01:16
|
|
|
Grump posted:I have a question about backend programming because I'm not a backend programmer and I'm not super clear on a lot of concepts. There's nothing wrong with sending data from the front-end to the server; the important thing is that the server checks and validates that data rather than just assuming that it was given good and accurate data. An HTTP request is a way of sending data, while an SQL query is data. They're different things, and can't replace one another. Think of an HTTP request as an envelope, whereas the SQL query is a piece of paper that you might put inside it. The piece of paper doesn't care what kind of envelope it's put into, though - it just needs to make it to its destination, and how it gets there is an implementation detail that (mostly) doesn't have any impact on what's on the paper. You're not too far off conceptually, you just need to worry a little less about what kind of requests you're sending. What exactly goes on in the backend is very much up to the details of your exact setup, but in general, your backend code will send requests to other back-end resources (like databases) and receive the results back. If the database and the server are on different machines, this will likely involve an HTTP request at some point, but you really shouldn't have to worry about how the data's being moved around unless you're doing something very complex or extremely performance-dependent. A basic workflow might be a little like this:
|
|
#
?
Oct 13, 2017 01:24
|
|
|
ahhhhh okay. So you really can't do CRUD functions to the database from the front end unless there's some backend code to execute the query. Right? But is it safe to have front-end forms that do POST requests and update a database?
|
|
#
?
Oct 13, 2017 02:04
|
|
|
It's a huge security hole for your front end to be able to connect to your database. You always have a server between the two. So, you POST to your server and then your server knows what to do with that data. Your front end doesn't know or care what the backend is doing with that data. Your backend could be writing each POST to its own text file on disk for all your front end should care.
|
|
#
?
Oct 13, 2017 02:21
|
|
|
Thermopyle posted:It's a huge security hole for your front end to be able to connect to your database. This is no longer true with modern web design. It is standard practice for many applications, including thick web apps, to connect directly to an offsite database. A lot of serverless models and mobile apps do this as standard. Serverless Stack is a step by step tutorial which includes how to do this.
|
|
#
?
Oct 13, 2017 03:46
|
|
|
Rapner posted:This is no longer true with modern web design. It is standard practice for many applications, including thick web apps, to connect directly to an offsite database. A lot of serverless models and mobile apps do this as standard. Can you summarize how they deal with security/ not allowing running arbitrary queries and bypassing business logic? Seems interesting and I'd love to see how they deal with that.
|
|
#
?
Oct 13, 2017 04:08
|
|
|
Lumpy posted:Can you summarize how they deal with security/ not allowing running arbitrary queries and bypassing business logic? Seems interesting and I'd love to see how they deal with that. It seems like the answer is by tightly coupling with Amazon services to emulate the server behaviour you need, which honestly feels disingenuous in terms of presenting this as 'serverless'. Does this actually reduce complexity, I'm not sure it does.
|
|
#
?
Oct 13, 2017 04:22
|
|
|
Grump posted:ahhhhh okay. You never, ever want to let the front-end talk directly to the database - that's how SQL injection attacks and other security flaws happen, because the user can freely manipulate what the front-end is sending and you can't really do anything about it. Feeding frontend input right into your database is basically inviting every malicious user out there to wreak havoc on your data. It's not a matter of "can you do it", because even if you can, you absolutely shouldn't. It's equivalent to publishing your database user credentials on your website for everyone to see. You absolutely need to have a back-end to sit in between and handle actually talking to the database. In a proper setup, the front-end tells the back-end what it wants to do to the database, and the back-end does the database editing (after it determines that the front-end's request is valid and makes sense, since again, front-end input is not trustworthy!).
|
|
#
?
Oct 13, 2017 04:43
|
|
|
|
| # ? May 16, 2024 14:42 |
|
|
Yeah. It isn't serverless. All it's doing is abstracting the concept of a server away behind some common API:https://serverless-stack.com/chapters/what-is-serverless.html posted:Serverless allows us to build applications where we simply hand the cloud provider (AWS, Azure, or Google Cloud) our code and it runs it for us. It also allocates the appropriate amount of resources to respond to the usage. I mean it's a cool concept, but definitely a misnomer. It's mostly aimed at allowing developers to create applications where they don't need to worry about back-end setup (provisioning, availability, etc). You're still giving Amazon or Google or whatever a set of instructions on how to handle different HTTP requests sent their way. Another good description: https://martinfowler.com/articles/serverless.html posted:Serverless was first used to describe applications that significantly or fully depend on 3rd party applications / services (‘in the cloud’) to manage server-side logic and state. Finally, a better analogy for the HTTP vs SQL (because you'd never put a SQL query [letter] inside an HTTP request [envelope]): Let's say you are a piece of server code. Your job is to open envelopes addressed to you and read the contents. Based on what is written, you need to take something out of your refrigerator and send it as a response. The mailman (the server's routing logic, which tells it what code should execute based on the incoming request) drops by and delivers an envelope addressed to you. This envelope is the HTTP request, and it can contain anything. You open the envelope to discover that someone has sent you a blank letter. Idiot. You do nothing and send back an angry response. This is validation logic written in the server side language leading to a HTTP error response code. The next day, the mailman drops by again. This letter tells you to get a FUCKYOU out of your refrigerator. You look in the refrigerator and find nothing by that description. This is the SQL query which returns a blank dataset. You send back an empty letter. This is a successful HTTP response with no data. On the third day, the mailman comes by again. This letter tells you to get a gallon of milk out of the refrigerator. You look in the refrigerator and retrieve a gallon of milk. Another SQL query that successfully returned data. You send a package to the person containing this milk. A successful HTTP response containing data. Finally the mailman delivers one final letter. This letter tells you to look for 1 OH and also throw away your refrigerator. Because your boss didn't make you parameterize your queries and wrote sloppy server side code, you just threw away a really expensive appliance and all the food went bad. But you were just doing what you were told. This is SQL injection. HTTP is the envelope. SQL is the instructions on how the server interacts with the relational database. Hope this helps. Ruggan fucked around with this message at 05:37 on Oct 13, 2017 |
|
#
?
Oct 13, 2017 05:34
|
|
