2,099 karma · joined February 15, 2012
(Assuming you learn from your failures)
I thought it was a play on 'bare' - e.g. only the basic features needed.
The solution here is not to 'fix' LDAP, it's to have proper processes for testing, change management, and deployment. It's to have non-production environments you can use, etc.
I know it's not particularly popular or trendy in startups, but these processes don't have to be onerous. Just some control over what you put into production. I'm not suggesting you wan avoid bugs, but there are in-depth mitigation you can take to help prevent this.
- Calendar (it can set up reminders in group chats and calendar)
- Camera/Microphone (to take pictures and videos to put in group chat)
- Contacts (to get a list of contacts! Also see SMS capability below)
- Location (you can send your location in a chat)
- SMS (it can act as an SMS client as well as FB chat)
- Storage (store received pics/videos, and access existing pics/videos)
- Telephone (to detect when you get an incoming call so it can handle any active activities (think if you're already on a video call)).
And as others have noted, you can disable most of these if you don't want them on recent Android versions.
Not infeasible to think you could use Lambda to generate a static cache of a WP site onto S3 and update files on demand.
For example, we use Google Apps at work with our custom domain, with an internal SSO server providing authentication services. You enter your email address, the Google page directs you to the internal SSO server, you get a token, take that back to Google, and you get logged in - no password required.
How is it a technical problem? Current web technologies allow decentralised web (except for maybe root name servers). Everyone can host their own content, control their own servers, basically everything below your hostname. The implementation has led down a centralised path.
Yes, so they just vote to close the question instead.
The main driver is that they don't need to have instance storage - that is, they can uncouple the storage from their compute nodes entirely and keep it on SAN somewhere.
Don't take this the wrong way, but you need to change the way you project yourself. Even just from this resume, you're talking yourself down. Who would you hire?
"I wanted to keep track of who/what was visiting my websites. Turns out they were mostly crawlers for search engines. I keep track of IPs and URLs requested, I store them in a MySQL database using PHP"
or
"Wrote an application to process and analyse logfiles across a collection of websites, using a common web application stack. Stores requested IPs and URLs for future analysis. Identified the split of automated search engine crawlers and other bots vs human visitors. Tools and languages used include PHP and MySQL"
Resumes are all about how you present what you've done.
On that point - if you're applying for frontend developer positions, use your skills! Build a cool website to present your resume rather than a plain piece of paper. You'll probably still need the paper, but the first line of it can be "View my resume online at example.com".
Whenever Apple or Samsung release an update for their smartphones, I have a to help family members click through dialogs to install them. How are they supposed to assess and implement security for an IP camera they bought at a department store?
How would they do it anyway? Is the expectation that they fire up Wireshark, identify traffic flows to and from their device, then configure the firewall on their consumer-grade router to limit this traffic?
[0] previously read just '... disconnect between this forum ...'
I couldn't get to CloudFormation template deploy working, so set it all up by hand, using the scripts in that repo as a base.
Once you figure out how it works, it becomes easy to start adding other commends to run (for example, I added some lines to invalidate CloudFront when I uploaded a blog post).
If I get a change over the next week or so I'll update a repo with the scripts I use, but as I said it's based on the above anyway.
I've now moved it into Lambda, so to post a new page to my blog, I drop the markdown file in an S3 bucket, and literally a few seconds later my blog is updated, Cloudfront and all.
So as I type this the votes are charging up the ranks (about 10 votes since I started typing this comment), so let me start off:
I can't possibly see how this is Amazon's fault. You're arguing that you offer a service for free (for a little while anyway), and that more people are taking you up on that because they have logs lying around, because Amazon has prompted them in the past to save these logs?
I mean, shouldn't this help your service?
a) now people can try it out because they already have logs and don't have to wait (which you've already identified was an issue), and
b) now people will end up with a bucket full of logs, think 'how can I analyse and use these logs', and go looking for a product like yours!
> It allows you to authenticate that the packet you received from the DNS server you connected to is the one that it sent, and also encrypts it over that single hop.
I guess the bit that's missing is, 'who is disagreeing with this?'
That's not the role of the tester. The developer should be writing and running their own unit tests. The Tester should be running through user scenarios, use cases, and basically be pretending to be a user of the software to make sure that everything works and makes sense in a workflow (not just in their unit components)