Which was fine until he revealed that he'd chosen them because that's what he always wore.
But now I gotta ask: you say it was fine until the reveal. Were they pictures of him in the boxers or just a brand he liked-or what did the reveal change for the team?
Good.
There are legitimate reasons to log requests. But far too often, developers that are used to 'printf debugging' will abuse the system. In many cases, what they were actually looking for was either some form of APM, distributed tracing, or much more commonly, would be better done by collecting metrics - which tend to be much more lightweight.
At work I've been fighting a battle to turn multiple dozens of terabytes of logs a day into something manageable, for years now. Sometimes I wonder if I could use the logging system itself in lieu of the application, as practically all data is dumped there! It's difficult battle to convince multiple groups to just use a counter instead of spitting out the same line of text every time the same kind of event happens.
Anyway, back to the point: no matter how busy the system is, you can surely engineer a mechanism to collect error logs, even if you have to sample them. But while things are running smoothly, track metrics. And, if you have a reason to suspect things are wrong, selectively turn on some logging.
I wish more people were aware of the costs of logging. Even more so nowadays, with the microservices craze.
As a result, all of our frontend servers slowed to a crawl because the logging calls were thrashing our disk I/O - and keep in mind, this is an application which never hits the disk and lives entirely in memory, mostly just assembling data structures from other APIs and combining them into a response for the client. To see a server like that brought to its knees by disk I/O from three lines of debug logging was... impressive, to say the least.
When I was younger, I used to while away time by browsing exotic vacation destinations (that I couldn't nearly afford) on travel websites. One day, I got an offer to work at one of them. After about a month there, the last damned thing in the world I wanted to spend my free time doing was looking at travel website destinations. Made me re-evaluate what sort of jobs I'd want to do day in and day out.
Now if you could figure out how to do it without either customers or bosses...
If you do what you love, what you love becomes work.
Is you do what you like, then you like your work, go home, and have energy for the things you love.
Some programmers write code at work and then do side projects on top of that. Other people enjoy knowing a little code, but would find it burdensome to write production quality code everyday. For them, programming is a hobby. Other people are content to program for their job and then leave it at the office and stop there.
People who have a hobby they love sometimes find their enjoyment is completely ruined if they try to turn it into a business. Loving something on weekends and evenings doesn't necessarily translate to being able to do it happily all day, everyday for work when other people are calling the shots and telling you how to do it.
I would say that, in this context, liking something means it is satisfying to you beyond the average activity. While loving something means that it is something you consider a part of your life - something that you feel you couldn't do without.
So working at a job which involves something you love can sap the joy out of it, because you end up doing that thing not for you, but for other people.
For programming the difference between what I like to do and what I can easily get paid to do is not that big, so it makes sense to combine as a career advice. But for hobbies like music or painting, unless you get extremely lucky, it is whole lot harder, takes much longer and requires to make much more compromises to get to the point where it is really fulfilling.
I only ever tried the latter semi-professionally. And it was already a soul crushing experience at times.
For it to make sense, at a minimum you have to also like and be pretty good at running a small business in addition to the thing that you love.
Several theories, probably something to each of them. The one I think explains the most is that if nobody is "passionate" about whatever you're doing, then you can approach things analytically, instead of having a layer of emotional investment gumming things up.
Personally, jobs that I thought the concepts/industry were interesting to me, but the work was far enough removed that it didn't sour me to the industry have worked out well. e.x. If you're a car guy, working on the software for an inspection company isn't too bad, you still come out liking cars, and wind up with some interesting stories.
OTOH, I've spoken with colleagues that have a bit more nuanced mindset: If they don't care about the product, that's fine, but they won't work for a company that sells a product they know they don't like, they won't do it.
The whole process sounded really seedy, and the parenting comments made by him the other guy who worked there were pretty distressing. Her kids (two boys, one girl all under 10) walking around while they were editing her porn scenes, all the marketing materials out in plain view of the kids as well.
He the nail in the coffin was when she stopped paying him and offered him sex instead for payment.
He said it was his first and last job in the industry. He said it also created a problem on what he should put on his resume for the time he worked for her. The suggestions on the site were pretty funny, but it was clear his experience was not like yours.
Was this company located in a building on the corner with a flag flying? And did you maybe sit at a corner desk on the 3rd floor?!
If so, how are you doing, its DanS :)
Had that problem at an ad tech company before. We just did sampling so that 1 in 10 or 1 in 20 requests would get logging.
It definitely made me wonder how many web servers out there have their performance determined by the rate at which logs can be written to disk.
As someone in the HFT space I suspect a lot of traders are performance bound by this. Wouldn't surprise me at all if a couple darkpools were this way.
For a looser definition of "traders" that includes dark pool operators and exchanges, then sure. Writing logs was definitely the bottleneck at one major European exchange for some years. They may not be able to turn off logging for regulatory reasons, but they also don't care so much about the microseconds. In this case they could definitely have improved performance with horizontal scaling (have each computer handle fewer stock symbols) but didn't consider that economically justified.
>You can always arrange for the logging to happen outside the critical path, which is a tiny minority of the code you run. And you will do that if its necessary to gain a fraction of a microsecond on a competitive trade. Even if it's just being able to run a build with logging off for special cases.
Yes you can do that. Yes you'd think that anyone for whom it would be beneficial would do that... but you'd be surprised how often people run with logs cranked to 11 in prod.
The company scammed and logged and sold the data as much as possible. The models were barely legal and a few looked like they were held at gun point. Lasted eight months up until I started getting nightmares and then the company went bankrupt. After receiving the first ever lawsuit in the UK for fake dating.
Did anyone have a chance to work at the company that created Ashley Madison? I always wondered what really happened there.
Would you mind elaborating on this please? I'm just trying to work out if you mean things like a custom user's menu, etc. you'd somehow pre-generate and then cache the HTML, or do you mean things like certain categories, etc. were just HTML?
Maybe i'm overthinking this, but would you generate a dynamic page once (ie. first time user logs into the site -> generate their "my account" page) and then cache it in memory, or as HTML on the disk, or set the cache control header and leave it to them locally?
thanks!
I believe you can put JAMStack on your resume!
Why do porn sites get so much traffic? Why do people enjoy consuming pornography as much as they do, at the volume/frequency that they do?
Everyone has different levels of libedo however, so it's likely that your lack of understanding is due to your own lower libedo not generating the same level of sexual desire. Or, you are the kind of person where the emotional connection involved in sexual relations is far more important, which obviously means watching people you have no connection to would not arouse you as much. Alternatively, it could be that you may have decent access to actual sex, which is obviously more gratifying as a general rule.
these sites get a lot of traffic(clicks and page views) and serve a lot of bandwidth(videos) but most users are just clicking around and watching just a few seconds to a couple minutes of any video they load(due to skipping). I think a lot of the traffic just people looking for the perfect scene or something new... there is a lot of junk on those sites these days.
source: i used to manage a number of high profile adult websites.
Tech was PhP, MySQL, memcache and similar vanilla stuff running on many Linux servers - pretty simple stuff.
The trick was performance. Simple stupid mistakes that would not be detected in sites that have low traffic become enormous problems in a high traffic server.
Pretty much nothing was dynamic and we wrote scripts to create static pages for almost everything except search and authentication.
Things like logging just could not be done. It was easier to load a bunch of data in memory on a request and process it instead of running a slightly slower SQL query, since a ton of those could kill the database.
And yes, there were no placeholder images or videos. After some time you just get used to it and code. But I have to say you get pretty desensitized to it and when I resigned from that job my life in that area improved quite a lot.
Highlights were p*rn stars and random celebs visiting the office - but after some time that got kind of meh.
The job itself was just a programming gig and very professional except for the images on the screen which we learned to ignore.
On the whole, the guys who ran the thing were a pretty solid and great bunch of people and it was one of the best dev experiences in my long career.