Yes, a little bit. If you gave me a word in a certain color font, that would take precedence. Its not like I was see "my" color. But if I thought of the word out of that context, it would be its normal color again (usually based on the color of the first letter like described in the article). Exceptions are things like logos which have a fairly strong association with certain colors.
It doesn't seem to. Text can be in any color and my synaesthesia stays the same. If the text itself was multicolored, maybe? I'm not sure. It doesn't come up that often.
I'm not the op, but I have the same grapheme–colour synaesthesia, and I perceive Google's logo in its original colors. But if I look at the word Google in plain text (or imagine it in my mind's eye) the coloration is different. [G] is kind of a brown, the [o]s are black, the [l] is white, and only the [e] at the end has any color, a bright green. I have to think about the individual letter associations; the brown and black dominate my perception of the word itself, but the vowels are a bit brighter. It's... kind of hard to describe, I'll admit.
I guess I should stress that I don't "see" these colors. I just know, intuitively, that they are there. They are the color of the letters in my mind's eye, if you will. I suspect thus that it has nothing to do with the shape of the letters, but is a side effect of how my brain processes the language, and understands the underlying phonemes. That would also explain why the vowels seem to be so much brighter, since they are the most important letters when I'm scanning text quickly for comprehension.
I've recently started adding L-theanine to my morning coffee every day, but I feel like I don't feel the effects after a few days, so I go a day without and then it feels normal again the next day. Have you ever had this?
It still does a pretty good job at preventing jitters. However, now that you say it, I think the first few times it had more pronounced effects. I'll have to try resetting my tolerance!
So basically if I had 200 automations I could run them on 200 lambdas and have them finish by the time the slowest one finishes? That pretty awesome, specially for testing. For many cases this would also fall under the free tier since it not that many requests/usage...it kinda seems too good to be true. Am I missing something?
> For many cases this would also fall under the free tier since it not that many requests/usage...it kinda seems too good to be true
(since I've ran into the same trap a couple of weeks ago and ended up with USD 650 of unanticipated charges): the free Lambda tier includes
* 1M requests
* 400k GB-seconds
--> the GBsec can be a serious bottleneck. Imagine you're running each Lambda instance with 512MB RAM and each instance takes 2 mins to complete your test. This means that one Lambda instance is ~61.5 GBsec, meaning you can execute ~6,500 of these instances per month to remain in the free tier.
Depending on how extensive your tests are/how often you run them, you might run out of free GBsec well before you'd run out of the requests quota.
Granted that means running ~216 instances per day, or 9 instances per hour (taking 18 minutes per hour to run total). Now you're right, if you're running a screenshot service then this will kill you real fast.
However assuming a 8 hour work day you then get ~27 instances per hour. Each test takes two minutes to run, so for a single user testing, assuming a code - test - code - test routine, you'd be able to do that nearly continuously, for 8 hours a day, every day of the month (no weekends or days off). Seems safe to assume that wouldn't occur.
Haven't had time to read the source yet, how are the lambda headless chrome reliability issues dealt with? Is it a different chrome build than serverless-chrome?
You guys should put up an example on how to convert a (small) test suit to use it, like you said you did in your top comment. The examples you have are cool but don't really help visualize that parallelism gain.
There's a section in the readme which I'm not sure of - "Running integration Tests for example is much faster." I guess that gains is from the parallel executions. But for the integration testings, there is still work to be done to make a central controller / runner to distribute various tests to different Lambda instances, correct? If that's the case, is loadtesting using Chromeless be another use case? Just initiate in parallel and blast the app infrastructure. It won't be efficient in terms of costs as using non-real browsers but this is probably as realistic as simulating real users load through real browsers.
> Terraform is basically this tool, but I want an even easier interface, terraform still feels somewhat too specific to me -- I don't want to even have to write config or specify some "aws" adapter that will make my config work on some provider. I want instant, multi-cloud (possibly) heroku, using only the network, hard-drive-space, ram, and lxc "primitives".
This sounds very similar to some ideas I've been stewing on over the past few months. One of them being a multi-cloud terraform-like tool which abstracts away the low level details of which provider an instance is provisioned onto (whichever is currently cheapest). It could also automatically determine how firewall/security groups/networking should be configured.
If you happen to create two instances in two different providers that need to communicate privately over say port 443, the security groups would be updated automatically to account for this, bridging the two providers.
One major thing to consider in doing this is the bandwidth. If you look at the fine print in these providers, the outgoing bandwidth is where they really get you. So if your backup server is in a different provider than your database, you might see some hefty data transfer fees while performing a daily backup.
Just curious, what's your background? Are you an infrastructure type, or are you a general developer who just wants a tool like you've described? Sometimes I can't tell if this is something people really want or if I've just drank too much of the infrastructure automation koolaid.
tl;dr - "Fullstack" developer who does my own ops for my own projects which are very varied (I've done small-time deploys/management for projects in/with python, node, go, haskell, ruby, postgres, rethinkdb). I try to iterate my infra as well as my technology stacks to find the best way to do things.
Sorry for the delay -- I've definitely had this at the back of my mind too, but with every advance made by cloud providers, I wonder if I could ever possibly get into that fight, especially since I'm not an expert at any of the cloud computing platforms -- Hashicorp seems to be doing amazing work in this area also, field seems to be full.
My background is basically that I really enjoy computers/programming and like to be self sufficient so I prefer a shallow (working) knowledge of all parts of the stack. I maintain a few VPSes and use them to host n-tier (where n is usually 2) projects. I'm always interested in the best way to do stuff and I use new projects to try stuff out.
Ops is particularly interesting to me because I've gone through a lot of iterations of how I did ops for my apps -- from SSH-in-and-do-stuff -> use-fabric-to-ssh-in-and-do-stuff -> dockerize & ship containers -> dockerized + systemd -> dockerize & registry (thanks to gitlab) + systemd + ansible. I've also used dokku and of course it blew my mind (I never used/wanted to pay for heroku), so while I stayed relatively low level, I was cognizant of what was happening a few levels up.
I saw kubernetes a few years ago and wasn't sure whether I wanted to go with it, but I've taken a fresh look over the last week and think it might be time to give it a try.
Side (controversial?) note - I think the time where it's acceptable for junior/mid-level developers to only know one part of the stack is dead. The only thing keeping these roles possible are the fungibility requirements for large corporations. Smaller, hungrier (almost literally) corporations can't afford to have some developer that is only an expert at writing python but never works on frontend code or deals with the database.
Your story sounds so familiar, someone could read what you wrote above and think it's me.. though I like to think of myself as a generalist rather than "fullstack". I tend to believe "fullstack" is a marketing term for acquiring slave labor. You're right though, it's required at this point for smaller startups.
> I wonder if I could ever possibly get into that fight
I wonder this too. I've been using AWS for 4+ years at my day job(s). The main pain point for almost all users, including myself is the cost. I think a product/tool that helps companies save on cloud costs would be invaluable. The difficulty is convincing crusty old ops people that the product is something worth trying.
Anyway, after my current employer runs out of money, I'm going to do a startup of some sort. While one of my many idea was like the one we outlined above, I'm actually starting to shy away from the infra/op verticals lately.
My email's in my profile, if you ever want to bounce ideas.
Agree -- "Generalist" is the word I'm going to use now instead of fullstack -- that's the way better term, I put "fullstack" in terms because I dislike the term.
I've recently installed Enpass and I'm currently in the process of evaluating it. I really like the idea so far. My main concern is that they're not charging enough and wonder if the business model is sustainable.
I've been doing something similar to your everydaycheck app, but manually using google sheets for about a year now. Works great for me too. Your app looks pretty neat!
Does it get much interest from others, or are you the main user?
Yes :) Happy to discuss in detail if you have specific types of abuse in mind. Our first line of defense is to get help from the community through downvoting useless content.
The main thing is how you are able to offer unlimited disk, when anyone can start uploading data? Some users might upload very large amounts of innocent data, others might simply abuse it as a sort of data backup system. More nefarious users might even try to distribute malware.
