Like with just about everything else we do, it's a balancing act. 1000 simple things to manage and keep in sync is no longer simple. 20 or even 10 may no longer be simple enough. But depending on the overall needs, 2 or 3 more moderate systems with looser coupling can make many things simpler to do than 1 giant, tightly coupled, mega-system.
But a giant monolith can work well for a long time. Instagram is still a giant monolithic Django site, for the most part, based on a recent (ish? not sure if it was a 2019 or 2018 thing) talk they gave about their deployment/ops stuff.
I just have never really seen it work unless it's a huge company that can devote the resources to manage it (amazon/google).
Every time someone tries to get fancy with these little things (I'm mostly talking about situations that move away from single points of failure, not really necessarily microservices) it's always just dozens of points of failure that happen to all get hit by the same bug and whoops away you go and now you're spending 3/4 of a day fixing the issue that would've been as simple as "spin up another vm, restore the backup from a few hours ago" that would take all of 30 minutes.
What other types of points of failure are you referring to? Complex build and deployment systems? 100% agreed there - a big part of my job is helping find the balance there between simplicity (usually far fewer points of failure) and flexibility (and the greater number of points of failure and greater number of failures).
On the microservice or at least "a few more, smaller services" front it depends on how far you want/need to go. Yeah, full on microservice all the things is asking for trouble most of the time and is not necessarily less work, just less stuff broken when something breaks if done right. But splitting up logically but not quite so granular can still have a number of benefits without quite so much overhead.
* deployments and changes which have a smaller area of effect - both at a code level and other infrastructure such as database changes, elasticsearch upgrades, etc. which all also may require software changes but now fewer of them at once.
* more cost effective horizontal scaling. Perhaps the piece of functionality which really needs scaled out a bit only needs to have 2 more ECS containers which cost say $15/month but other parts of your platform don't actually need more workers, but if a monolith would require you to add 2 more $100/month ECS containers. * smaller/ligher weight apps which require less startup time, improving scaling response, deployment times, etc.
Real world example similar to (but not exactly the same) as the 2nd bullet there: I just helped a client this last week move a nasty html -> pdf build which required them to maintain 1-2 (auto scaling) $150/month ec2 instances which were still occasionally crushed by a large pdf build (btw, weasyprint kind of sucks) which only needs a single $30/month one 99% of the time by rewriting the pdf generation part as an aws lambda microservicey deal which I will be surprised to see ever cost them more than $5/month and will possibly never incur any cost.
There's rarely an "always right" or "always wrong" (except 100% uptime on things other than pacemakers). It's about what your goals and needs are and what resources in both general manpower and knowledge you have available to reach those goals.
I've been doing some Python tutorials and I've run into a snag that seems very simply but I've not been able to figure out. The tutorial seems to jump between Python 2 and 3 without warning so it might be related. I also probably need to seek out a more consistent tutorial.
Regardless, anyone have any clue why this class would give me a "TabError: inconsistent use of tabs and spaces in indentation" on the name_pieces line ?
All the tabs are 2 spaces each and the editor (Brackets) doesn't flag any of the indents. I'm missing something obvious I'm sure but I don't realize what =p.
EDIT - ugh...been messing with this a while and as SOON as I post it, I figured it out. Apparently my bottom part only needed one indention.
Glad we could be your rubber duck!
Programmer hot tip: buy an actual, physical rubber duck. Keep it on your desk. Next time you're stuck on a problem...explain the problem to the duck. Out loud. Ignore all of the crazy looks your coworkers give you.
Half of the time, this will bring you closer to the answer than you were before.
I've been doing some Python tutorials and I've run into a snag that seems very simply but I've not been able to figure out. The tutorial seems to jump between Python 2 and 3 without warning so it might be related. I also probably need to seek out a more consistent tutorial.
Regardless, anyone have any clue why this class would give me a "TabError: inconsistent use of tabs and spaces in indentation" on the name_pieces line ?
All the tabs are 2 spaces each and the editor (Brackets) doesn't flag any of the indents. I'm missing something obvious I'm sure but I don't realize what =p.
EDIT - ugh...been messing with this a while and as SOON as I post it, I figured it out. Apparently my bottom part only needed one indention.
Glad we could be your rubber duck!
Programmer hot tip: buy an actual, physical rubber duck. Keep it on your desk. Next time you're stuck on a problem...explain the problem to the duck. Out loud. Ignore all of the crazy looks your coworkers give you.
Half of the time, this will bring you closer to the answer than you were before.
You just trade "site is offline" for "cloudflare can't talk to your stuff". Trying to achieve anything past 98% uptime when you're not a data center is just an exercise in futility.
Change my mind.
We have some fluffly "ensure 100% cloud uptime" sentence in our corporate goals and nobody on the tech side of the company has any idea what that means. :rotate:
I have been firing this quote - straight from google along with a few of google's own uptime requirements/sli stuff at people lately when they bring me this 100% uptime crazy talk. Many of google's are lower than that 99.999% as well.
100% is the wrong reliability target for basically everything. Perhaps a pacemaker is a good exception! But, in general, for any software service or system you can think of, 100% is not the right reliability target because no user can tell the difference between a system being 100% available and, let's say, 99.999% available.
Pacemaker software isn't actually 100% reliable. It's designed to have 0% false positives.
But safety critical software has a whole different set of constraints you account in addition to availability.
I find a lot of overlap between games and Advent of Code - you tend to implement a lot of similar things (maze searches, decision trees, dealing with inputs and outputs, etc).
Are you a Software Engineer living in Seattle? HBO is hiring, message me.
I haven't done any real programming since high school (which amounted to making bad games in Visual Basic and swearing at Java), but I'm wanting to cook up a simple dicebot for IRC. Easy enough for a beginner project or am I gonna run into something complicated? Is any particular language more appropriate for this job than others? I tried installing a few on my Ubuntu server off Github that were written in either Ruby or Python and none of them work and they hadn't been updated in 8 years, so here I am.
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Python would be my go-to language, but I haven't looked into IRC modules. The spec is dirt simple though, and it would be straightforward to implement if you wanted to go down that road.
A dicebot is simple. Complications are only if you want to get complicated, like define a grammar for it (e.g. allow mathematical expressions, of which dice rolling can resolve into a value), start adding in RPG tracking (e.g. mana, health, etc.), or other fun stuff.
Yeah, as a Python dev by day anyway, Python would be my first choice for something like that. If you want to avoid the actual interractng with the IRC protocol part, I know many (most?) IRC clients support writing bots via some combo of Lua, Python, or a homegrown scripting language and so it may be worth starting there if you want to keep things simple.
You can cook up a simple Python bot in a few hours of work if you know what you're doing, a few days if you don't. I made a reddit bot a few weeks ago and it was surprisingly easy in Python, it's a great language for stuff like that.
Yeah, 3 it's definitely where I'd start now. For a long time there was a lot of advice to start with 2 since everyone had to port their libraries over to 3, didn't want you to get stuck in that.
I'm pretty sure 2 is getting EoL'ed here soon, at least by the official Python org. 2 is still used by a bunch of system libraries on most (all?) flavors of nix and has to be on the path so it'll be interesting to see how that all plays out.
Sigh. Hey, does anyone have any suggestions for good quick "starting Android for dummies" kind of tutorials?
Cause the lectures where we were supposed to get explained the basics of Android programming and environment got canceled, but the fact that we have to turn in a small project in Android next week did not, in fact, get cancelled with them, and I know fuck all about Android.
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
For a very large number of teams, this winter and spring is the era of frantically porting Python 2 stuff that hasn't been touched in years to Python 3.
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
For a very large number of teams, this winter and spring is the era of frantically porting Python 2 stuff that hasn't been touched in years to Python 3.
Let's be honest. They'll just require people to install unsupported insecure software.
Just curious, what makes Python better suited for a dice bot than the average modern language? You need random, regex, and a way to read/write text. s it just that that's what the clients support, or something intrinsic to the language?
0
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Nothing about Python makes it better suited to anything than any other modern language. Even it's famous card trick, list comprehensions, are available at the library level in almost every modern environment. I would say the allure of Python for a beginner at this point is the community support plus the breadth and depth of learning resources for it.
Yeah, nothing super specific. I personally find it to be a very clean looking, easy to read and decipher language due to the emphasis on clarity and explicitness and relative lack of magic while still providing the the ability to create/use nearly any magic you may deem worthwhile.
Speaking of Python, if I had a bunch of string/dictionary type data that (in another language) I'd store as some kind of struct, enum, etc, what would be the proper Pythonic way of doing so? Dicts work, but dot-syntax would be so much more convenient... Data classes seem almost but not quite what I'm wanting, but that not-quite could be due to me not being as fluent in Python as otherwise.
Edit: Oh sod, I should have looked up Python enums. I assume I'm not committing a language sin by using them so?
dporowski on
0
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
There's also named tuples. IDK if that helps, but I know I'm always forgetting about them.
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
A dev took over one of our old projects for a while and we just got it back. I assume he'd just read an article on how great dependency injection is because every piece of logic has been exploded into a thousand little services. I mean, why use ToLower() on a string when you can inject your own super special translator...
public class LowerCaseTranslator : ITranslator
{
public Task<string> TranslateAsync(string value)
{
if (value != null)
{
return Task.FromResult(value.ToLowerInvariant());
}
return Task.FromResult<string>(null);
}
}
0
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
edited January 2020
Oh, it's Async too. So when you don't want the performance hit of calling ToLower inline you can dispatch that call.
Edit: I'd be tempted to ask him to make it as a lookup table to see if he figures out it's a simple byte subtraction.
There's also named tuples. IDK if that helps, but I know I'm always forgetting about them.
Also possibly useful, thank you! Python enums seem to be similar enough to Swift that I'm getting a lot of the functionality I reflexively want, so I'm not unhappy with it so far. However, I always take all the advice I can get my hands on.
Posts
What other types of points of failure are you referring to? Complex build and deployment systems? 100% agreed there - a big part of my job is helping find the balance there between simplicity (usually far fewer points of failure) and flexibility (and the greater number of points of failure and greater number of failures).
On the microservice or at least "a few more, smaller services" front it depends on how far you want/need to go. Yeah, full on microservice all the things is asking for trouble most of the time and is not necessarily less work, just less stuff broken when something breaks if done right. But splitting up logically but not quite so granular can still have a number of benefits without quite so much overhead.
* deployments and changes which have a smaller area of effect - both at a code level and other infrastructure such as database changes, elasticsearch upgrades, etc. which all also may require software changes but now fewer of them at once.
* more cost effective horizontal scaling. Perhaps the piece of functionality which really needs scaled out a bit only needs to have 2 more ECS containers which cost say $15/month but other parts of your platform don't actually need more workers, but if a monolith would require you to add 2 more $100/month ECS containers. * smaller/ligher weight apps which require less startup time, improving scaling response, deployment times, etc.
Real world example similar to (but not exactly the same) as the 2nd bullet there: I just helped a client this last week move a nasty html -> pdf build which required them to maintain 1-2 (auto scaling) $150/month ec2 instances which were still occasionally crushed by a large pdf build (btw, weasyprint kind of sucks) which only needs a single $30/month one 99% of the time by rewriting the pdf generation part as an aws lambda microservicey deal which I will be surprised to see ever cost them more than $5/month and will possibly never incur any cost.
There's rarely an "always right" or "always wrong" (except 100% uptime on things other than pacemakers). It's about what your goals and needs are and what resources in both general manpower and knowledge you have available to reach those goals.
This sounds much better than my “frantic, stressed out conversations with myself in the hall” thing I did in my labs this term.
Switch: nin.codes/roldford
Eh... Yeah you'll probably still do those.
Pacemaker software isn't actually 100% reliable. It's designed to have 0% false positives.
But safety critical software has a whole different set of constraints you account in addition to availability.
Luckily I had implemented the exact algorithm I needed when I wrote my game Penny and Paul's Adventures a decade ago.
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
Do... Re... Mi... So... Fa.... Do... Re.... Do...
Forget it...
A dicebot is simple. Complications are only if you want to get complicated, like define a grammar for it (e.g. allow mathematical expressions, of which dice rolling can resolve into a value), start adding in RPG tracking (e.g. mana, health, etc.), or other fun stuff.
It's only limited by your imagination and needs.
I'm like THIS close to finally moving to a place where I won't have to work with SharePoint anymore and it's killing me.
Off we go!
Do... Re... Mi... So... Fa.... Do... Re.... Do...
Forget it...
Do... Re... Mi... So... Fa.... Do... Re.... Do...
Forget it...
I'm pretty sure 2 is getting EoL'ed here soon, at least by the official Python org. 2 is still used by a bunch of system libraries on most (all?) flavors of nix and has to be on the path so it'll be interesting to see how that all plays out.
Cause the lectures where we were supposed to get explained the basics of Android programming and environment got canceled, but the fact that we have to turn in a small project in Android next week did not, in fact, get cancelled with them, and I know fuck all about Android.
https://developer.android.com/training/basics/firstapp
Let's be honest. They'll just require people to install unsupported insecure software.
That feels weird to say. Is that weird?
Every time I use it I miss something from Swift, though. Today it was structs.
pip install irc
import irc
irc.connect("some.server.org:6667")
irc.join("#mychan")
and in about an hour (or possibly 5 minutes) have a dicebot.
Edit: Oh sod, I should have looked up Python enums. I assume I'm not committing a language sin by using them so?
public class LowerCaseTranslator : ITranslator { public Task<string> TranslateAsync(string value) { if (value != null) { return Task.FromResult(value.ToLowerInvariant()); } return Task.FromResult<string>(null); } }Edit: I'd be tempted to ask him to make it as a lookup table to see if he figures out it's a simple byte subtraction.
Someone hasn't heard the good word of Unicode!
Also possibly useful, thank you! Python enums seem to be similar enough to Swift that I'm getting a lot of the functionality I reflexively want, so I'm not unhappy with it so far. However, I always take all the advice I can get my hands on.
"Sure thing."
(rummaging through attached documentation) Let's see, we have design docs, model requests and responses, credentials...and no API spec.
Welp, this just hit a brick wall.
Best comment in that twitter thread: "Thanks for curing my impostor syndrome."
Well then
This makes me feel much better about myself