Log (and presumably) deal with errors if you _can deal with them_ close to where they occur. Otherwise just let them throw and/or propagate them up. An application should have some sort of top level error handling to log the error and actually return a response (HTTP 500 or otherwise) to the client.
For something like a library: no logging, that's not a library's job -- unless it's a logging library! If the language has exceptions, then throwing only subclasses or implementations of a single exception parent/interface from the entire library is nice for clients of the library.
Most mature languages have a logging system which allows the internal logging of a library or module to be silenced, redirected or almost any other action. I think there is a lot of value in libraries doing appropriate logging which can't easily be replicated in application code.
An example which comes to mind because I happened to be looking at it is the python Requests library where they log inform about when new connections are created / destroyed which is very useful when debugging keep-alive.
> Most mature languages have a logging system which allows the internal logging of a library or module to be silenced, redirected or almost any other action. I think there is a lot of value in libraries doing appropriate logging which can't easily be replicated in application code.
Info/debug level logs sure, I don't disagree. As long as there is some built in or community standard logger and not the libraries own custom thing.
Errors, I'd rather they throw and my own app's logging facilities kick in that can provide more context: which server, which container, request info (method, path, request ID), etc. Granted some of that could come from configuring a logger with it.
Same for me. Kids are 1.5 and 4. I used to do so much just hacking around, and now it's non-existent.
As far as bedtime/sleep stuff: I pretty much just wind down after the kids go to bed. Meditate if I haven't got that in yet (or maybe do a shorter session if I have and am feeling stressed). Read. Then try to get to bed early enough to give myself an 8-ish hour sleep window.
I think all non-managers should read it as well as it will give you some clarity on what you should expect from your manager and what their day-to-day is like.
I tend to write test cases that re-produce bugs first, then fix the bug. Other than that, I don't stick too hard to test driven development. I did for a while, but you start to get a sense of the sort of design pressure tests create and end up build more modular, testable code from the get go anyway.
> Can you describe the practical benefit?
For a test case that produces a bug, you might find the bug manually. Getting that manual process into a test case is often a chore, but in doing so you'll better understand how the system with the bug failed. Did it call collaborators wrong? Did something unexpected get returned? Etc. In those cases, I think the benefit really is a better understanding of the system.
> Do you happen to rewrite the tests completely while doing the implementation?
A TDD practicioner will probably tell you taht you're doing it wrong if you do this. You write the minimum viable test that fails first. It might be something simple like "does the function/method exist". You add to your tests just in time to make the change in the real code.
Though it may have started as a, "parasite upon reddit," imgur does stand pretty well on its own now. Try out their mobile app and you'll see a pretty active community.
It could successfully metamorphise. Without reddit, it would have less traffic, but also less hotlinking, so it might be more profitable. But reddit traffic might be its lifeblood, I'm not sure.
Advertising. Definitely first party data for targeting. An advertiser takes some data from its CRM, sends it to the big social sites and google, and then uses the list to target those folks specifically or create look-a-likes. Actual cross device targeting (because people are logged in), extremely personalized and relevant.
That's advertisers themselves doing a bad job of retargeting. First-party data is probably not going to change that. In fact, it may mean you'll just get those ads across all your devices.
PMG | Senior Backend or Frontend Engineers | Fort Worth, TX | https://www.pmg.com/ Onsite or Remote, Full-Time
PMG is looking for some senior-level engineers to help us build in house advertising tools. These are usually more than just web apps and tend to be fairly interesting to work on. PMG works with a lot of high end fashion/retail and travel clients (https://www.pmg.com/clients/).
Lots of freedom to choose your own technologies, but we use a lot of PHP (Symfony, Doctrine), Python, JavaScript, and Go currently along with the usual mix of databases (Elasticsearch, MongoDB, MySQL, PostgreSQL, Redis).
This is how I came to work remotely. When my wife and I had to move for her job, I had built quite a bit of the software my company relied on. Had leverage to go remote and the trust of my boss to do so.
I suspect it's because WhatsApp's backend can be turned into a platform that will run WhatsApp itself as well as Facebook Messenger.
There's a lot more opportunity to do messaging between businesses and individuals (eg. customer service) as well -- see messenger for business.
Not saying Facebook isn't out to sell ads, just that there's probably a lot of reasons that Facebook might want WhatsApp's technology and team. Especially as they try to move more conversations onto their platform and reach out into other markets.
I imagine the biggest driver was what people postulated at the time.
It's the messaging app that the most people are using. It's used for updating groups of friends, sharing photos and all the other stuff that Facebook needs to be The Place for. It also has a simple, organic-ish mole for deciding who sees what and when that intuitively makes sense to people. IE, you don't have to twiddle with circle settings to find the nexus of friend-work and professional-friend that should see your message. Instead it just has groups that start out as "who wants to watch the fight at the bar" and sometimes people keep posting to them.
Whatsapp could have pivoted or been acquired for directly competing with Facebook.
Nonsense. Google's acquisition of Applied Semantics (which developed AdSense) became a major revenue engine for the company. There are countless other examples as well.
If your objects require dependencies to do their jobs, it should be impossible to create objects without those dependencies. The objects' constructors should require them. Having setters is, arguably, fine (but probably unnecessary) as long as invalid objects can't be created.
For something like a library: no logging, that's not a library's job -- unless it's a logging library! If the language has exceptions, then throwing only subclasses or implementations of a single exception parent/interface from the entire library is nice for clients of the library.