froztbyte

in a freshly created venv, with attrs and ipython (and deps, of course):

  (attrs) % ipython
  Python 2.7.14 (default, Oct 19 2017, 23:28:49)
  Type "copyright", "credits" or "license" for more information.
  
  IPython 5.6.0 -- An enhanced Interactive Python.
  ?         -> Introduction and overview of IPython's features.
  %quickref -> Quick reference.
  help      -> Python's own help system.
  object?   -> Details about 'object', use 'object??' for extra details.
  
  In [1]: import attr
  
  In [2]: Part = attr.make_class("Part", ["part_num", "description", "quantity"])
  
  In [3]: Part?
  Init signature: Part(self, part_num, description, quantity)
  Docstring:      <no docstring>
  Type:           type

Outside of the name of the thing that creates the item, the syntax is identical to what you have here.

edit: removed triple backticks, indented with 2sp according to https://news.ycombinator.com/formatdoc rules

Really awesome to see how far this has come with the development since its original form! Nicely done!

Very early on:

* time tracking: a frankenstein combination of system logs (especially helpful when jumping between workstations), paper notebook, and chatlogs

* invoicing: http://billable.me/

* both: some elbow grease

Evolution (and current, w/ a small team):

* time tracking: http://getharvest.com/

* invoicing, accounting, etc: https://www.xero.com/

The first one carried me for a few months, at an average workload of 60~140h/mo and a maintenance workload of about 4 hours total.

The latter is solving somewhat different problems, but does equate to time won on the admin side.

Depends on many, many things. Most are fairly specific to the region in question (whichever it might be).

Yeah... it's tough..

Still, I'm sticking around. There's potential to do good here.

As a mini-followup: due to this kind of scenario, we ended up having to replace UPS battery packs in about 8 months (1/3 of their minimum intended lifecycle) due to how heavily they got load-rushed over the months.

The load cycle literally killed them in that time.

Ah, no no. The expectations are not low.

People are paying for a service, and they expect it to work.

I once (another country, another ISP) dealt with a query/complaint of "it doesn't work!" which turned out to be due to a snowstorm taking out _the entire area_. Which people knew about! And still complained!

The expectation for the service is really much of the same.

Almost ironically, the first marker that people phone about is "my email doesn't work!"

edit/addendum: your customers also have their own solutions for dealing with power outages - more UPSs, generators, laptops (with internal wimax or 3G chips), etc

By way of answering, let me recount a short story for you.

It takes place during the very first time I visited Kampala (the capital of Uganda). It was about 3 years before I had started working in the ISP/telecom space in Africa. This particular trip was soccer-specific (I was working on the team that delivered one of the big trans-national African tournaments' games on television), thus the non-ISP nature of it.

We arrive at our hotel, having driven just under an hour from Entebbe to Kampala. It's fairly pleasant, albeit a tad humid (it's mid-day and near the equator after all; 36C and >=70% humidity - not the worst). There's a group of around 30 of us that now need to check in... this always takes a little while.

So, everything goes on. You loaf around the hotel reception until it's your point in the queue, grab some water now and then when you can. Finally, you're standing at the front desk, starting your process of checkin.

You read off your name... the person behind the counter finds you in the list (of fortunately mostly checked-off people - yay alphabet precedence!), and starts doing some stuff on the front desk computer. At which point you glance over to said desktop and notice the UPS jacked into the UPS jacked into the UPS (yes, three) jacked into the computer. You idly inquire about this. The response is "oh, yeah, the other ones died with all the power outages".

Not a joke, as it turns out. While you're doing your checking, the building experiences a brownout twice.

Years later, you get there for a totally different reason. Time (literal years) has passed. And during setup of some equipment (here, I'm skipping about two days' worth of time), you find that the reason your laptop screen kept dimming and your DC UPS' kept beeping.... is because you're getting such major voltage swings on the building feed that everything is going over-or-under-voltage.

This is daily life (in many parts of Africa). It isn't a thing to fight against. It just is. You take it, and try to do your utter best. You try to deliver your utter best.

And if you just push hard enough (and, imo, if you're really, really lucky) you maybe get somewhere with it!

Nothing exciting published, no. Blogging wasn't particularly big around this part of the world/specific-weird-subset-of-the-market for most of that time. Should I consider writing up some of them?

Past aside, there are many things already underway, in many areas, that you could be involved in if you wished. Do some research around areas that you find yourself interested in (both technologically, and geographically), and see where that takes you.

(all below is in an American/US context)

Read about ILECs/CLECs. Understand what the cable offerings' contention model is.

Do the math.

Understand the support burdens of NAT-on-NAT.

Run the numbers of RF contention, and shared-medium bandwidth management.

Do the math.

Probably the best advice I could give here: It's very easy to do a mediocre job of all this. It's a fair bit harder to do a good job of it. And think of how much you dislike the mediocre ISPs.

While I don't wish you ill will, I do wish to remark that you have had it remarkably easy with this.

Source: 7 ISPs. In Africa. On unreliable power, broken fibre, people stealing your spectrum, etc.

Will contact separately.

Someone with an interest in the liveliness of open-source ecosystems.

I didn't find enough relevant data out there, so I decided to get some.

First to get some more responses.

Later, if possible, I'll attempt to release the raw (albeit sanitised) data.

At minimum I'll post a follow-up with some statistics/analyses.

"How unreliable is UDP? Let's test with these 5 network paths that I have no control over, and have no idea what their design constraints are...that should be totally authoritive, right?"

Pretty bad test conditions on this, tbh.