Going through the history of a method in git and I'm just floored at how useful these git commit messages are. Really makes pin-pointing what happened to this method a breeze.
No, wait, the other thing.
The one about the fucking space hairdresser and the cowboy. He's got a tinfoil pal and a pedal bin
a lot of mine are like that too, sometimes I will put what it is in the commit's description
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
I only do that kind of thing for internal commits before I collapse them and make a proper commit message: one that has a link to the associated task in the tracker, and a high level description of what changed and why.
Commit messages like "bug fixes" need to be squashed; they're a bug in the process!
It's never an appropriate commit message. If one can't think of 7 words to describe what they are committing, just don't commit it to the codebase. k10xbye.
+6
Options
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
I hate our recruiters and HR so much some days.
We have an open position for a developer. We use C/C++ and C#.
I've got a phone screen tomorrow with someone who has JavaScript, Django and jQuery experience.
We have an open position for a developer. We use C/C++ and C#.
I've got a phone screen tomorrow with someone who has JavaScript, Django and jQuery experience.
This is gonna be interesting.
I spoke to a "Machine Learning engineer" with 6 years of javascript experience, an udacity course and 3 months of ML. Just roll with it and try to move on fast.
does anyone know if the django local testing server is *supposed* to fail under load?
Like, I understand you're not supposed to use it for real projects, and I'm not
All I'm doing is testing it locally and running a battery of requests in sequence against it as a sort of unit test, and if I give it anything more than a few requests per second, it simply dies
that seems exceptionally poor even by development server standards... i'm trying to figure out if this is the server at fault, or some part of my test at fault
does anyone know if the django local testing server is *supposed* to fail under load?
Like, I understand you're not supposed to use it for real projects, and I'm not
All I'm doing is testing it locally and running a battery of requests in sequence against it as a sort of unit test, and if I give it anything more than a few requests per second, it simply dies
that seems exceptionally poor even by development server standards... i'm trying to figure out if this is the server at fault, or some part of my test at fault
Socket limits and connections not being closed/reused by testing framework?
Going through the history of a method in git and I'm just floored at how useful these git commit messages are. Really makes pin-pointing what happened to this method a breeze.
We do have a spec document on how the JSON you are supposed to be sending through my API should be formatted. A lot of your "it's throwing an error, what do I do?" messages could be resolved by taking 5 minutes to review the spec and making sure your response is conforming.
Today I'm dabbling with etcd, which we use here to tell our DNS that services are alive. That bit is actually handled by a central service that gets updated values when Fleet deploys stuff, which I'm not really a fan of. (I'm also not really a fan of Fleet. Yes, we plan to move away from it.)
This sprint I finally have some Prometheus time planned after all the shit that had higher prio, now that we have a new dev on the team. So I'm looking at etcd for service discovery so Prometheus can find services to scrape metrics from.
The Go client lib for etcd is quite excellent. Wrote an etcd announcer in like 90 lines with all the features I'll need, and just got done with an etcd watcher that monitors etcd for updates in another 90 lines - really simple stuff once I got the hang of etcd concepts.
Once I have those polished a bit more I'll start adding the announcer to services, and write a Prometheus exporter for the watcher that grabs all announced services from etcd and writes to a JSON file that Prometheus monitors to find scrape targets.
the answer to my unit testing woes seems to be that the django localserver has a finite concurrency limit, and for reasons not yet fully understood, Apple is ignoring my numerous requests to only send one request at a time, and just force feeding the entire block of requests through as fast as possible (thousands)
then I can slowly creep up the concurrency to the exact breaking point... but it handles 20 simultaneous requests with ease, and somehow my unit test is exceeding that
on the sunny side, this demonstrates that it is probably also an issue in production, but I haven't noticed it because I have Cores For Days in production, and the limitations of cell connections provide a nice artificial throttle
Jasconius on
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Which works so well when you need to scale up the number of developers or hand off a project to someone else...
(I'm experiencing this now, and it is a right pain in the ass)
It's a "prefer", not "don't do".
Unfortunately, there's a pretty wide gap between "basic documentation" and "system level understanding sufficient to make deep changes to system functionality"
the answer to my unit testing woes seems to be that the django localserver has a finite concurrency limit
Ooo, ooo, what do I win?
an entire dollar! the mystery is how I am managing to violate it. the iOS libs have concurrency and max-socket settings, all of which I've set to try and prevent this
ThingVM thingVM { get; set; }
...
Visibility="{Binding thingVM.showStuff,Converter={StaticResource BoolToVisConverter} }" <!-- the converter is set up elsewhere -->
then please tell me that I need to make thingVM public, so I don't burn two hours trying to debug the awfulness that is XAML bindings and wondering why stuff isn't showing.
I wouldn't mind quite so much if this wasn't exactly the same problem that I wasted two hours on yesterday. You'd think I'd remember, but no.
the answer to my unit testing woes seems to be that the django localserver has a finite concurrency limit
Ooo, ooo, what do I win?
an entire dollar! the mystery is how I am managing to violate it. the iOS libs have concurrency and max-socket settings, all of which I've set to try and prevent this
and yet, it continues to go nuts.
Oi! Ab has never actually worked on Apple. We swapped to httperf because of unhappy hipsters saying how "make stress" fucks up on anything non-linux. Then decided this is shitty too, and setup actual stress testing with log replaying. That was the first thing that actually felt useful.
We do have a spec document on how the JSON you are supposed to be sending through my API should be formatted. A lot of your "it's throwing an error, what do I do?" messages could be resolved by taking 5 minutes to review the spec and making sure your response is conforming.
Can I talk about how much I hate the brave API future? A lot of folks think having an API checks the data availability box, but don't care if it doesn't have a good dataset or isn't performant. So frustrating.
We do have a spec document on how the JSON you are supposed to be sending through my API should be formatted. A lot of your "it's throwing an error, what do I do?" messages could be resolved by taking 5 minutes to review the spec and making sure your response is conforming.
On one hand, yes absolutely. On the other hand, does your spec have some inane bullshit that is easy to miss? Had a contractor writing a module for our stuff at one point, connecting to a third party API and kept getting error after error. Data was submitted as JSON, and at the top of the spec sheet it said this. And then right before all the examples, about 10 paragraphs of corporate BS later, there was a single line that said "All JSON data should be formatted as a single string with |'s separating the calls and values."
So instead of say, having:
data = {
call: 'Test',
info: 'This is a test call',
moreInfo: 'Still just a test call'
}
You were supposed to do:
data = "{call: 'Test' | info: 'This is a test call' | moreInfo: 'Still just a test call'}"
Which is just like...what in the ever living fuck?
The best part is, they went to the effort of creating their own data format, which means they needed to go to the effort of building their own parser for that format. What's the bet their parser was fragile and could break in ways that a regular JSON.parse() library would handle just fine?
We do have a spec document on how the JSON you are supposed to be sending through my API should be formatted. A lot of your "it's throwing an error, what do I do?" messages could be resolved by taking 5 minutes to review the spec and making sure your response is conforming.
On one hand, yes absolutely. On the other hand, does your spec have some inane bullshit that is easy to miss? Had a contractor writing a module for our stuff at one point, connecting to a third party API and kept getting error after error. Data was submitted as JSON, and at the top of the spec sheet it said this. And then right before all the examples, about 10 paragraphs of corporate BS later, there was a single line that said "All JSON data should be formatted as a single string with |'s separating the calls and values."
So instead of say, having:
data = {
call: 'Test',
info: 'This is a test call',
moreInfo: 'Still just a test call'
}
You were supposed to do:
data = "{call: 'Test' | info: 'This is a test call' | moreInfo: 'Still just a test call'}"
Which is just like...what in the ever living fuck?
There just aren't enough stabbing knives in the world for fuckery like this.
We do have a spec document on how the JSON you are supposed to be sending through my API should be formatted. A lot of your "it's throwing an error, what do I do?" messages could be resolved by taking 5 minutes to review the spec and making sure your response is conforming.
On one hand, yes absolutely. On the other hand, does your spec have some inane bullshit that is easy to miss? Had a contractor writing a module for our stuff at one point, connecting to a third party API and kept getting error after error. Data was submitted as JSON, and at the top of the spec sheet it said this. And then right before all the examples, about 10 paragraphs of corporate BS later, there was a single line that said "All JSON data should be formatted as a single string with |'s separating the calls and values."
So instead of say, having:
data = {
call: 'Test',
info: 'This is a test call',
moreInfo: 'Still just a test call'
}
You were supposed to do:
data = "{call: 'Test' | info: 'This is a test call' | moreInfo: 'Still just a test call'}"
Which is just like...what in the ever living fuck?
...this is where I start looking for guilty fingers to break.
we've got an internal format caused by someone on our data team sending us some output where each line of the file is a different validly formed json, the .jsons format
0
Options
AkimboEGMr. FancypantsWears very fine pants indeedRegistered Userregular
we've got an internal format caused by someone on our data team sending us some output where each line of the file is a different validly formed json, the .jsons format
That's actually a thing. It's called ndjson for newline-delimited json. I don't know how common it is, but at the very least I've seen it used in Google's BigQuery and Pandas (the python library) supports it as well.
AkimboEG on
Give me a kiss to build a dream on; And my imagination will thrive upon that kiss; Sweetheart, I ask no more than this; A kiss to build a dream on
Posts
https://github.com/Microsoft/GVFS/issues/70
Nice.
No, wait, the other thing.
Commit messages like "bug fixes" need to be squashed; they're a bug in the process!
Son, I squash bugs like you on the way to developing real features
We have an open position for a developer. We use C/C++ and C#.
I've got a phone screen tomorrow with someone who has JavaScript, Django and jQuery experience.
This is gonna be interesting.
I spoke to a "Machine Learning engineer" with 6 years of javascript experience, an udacity course and 3 months of ML. Just roll with it and try to move on fast.
when they write fizzbuzz, ask them to actually compile it without google
Like, I understand you're not supposed to use it for real projects, and I'm not
All I'm doing is testing it locally and running a battery of requests in sequence against it as a sort of unit test, and if I give it anything more than a few requests per second, it simply dies
that seems exceptionally poor even by development server standards... i'm trying to figure out if this is the server at fault, or some part of my test at fault
Socket limits and connections not being closed/reused by testing framework?
its possible that it's not doing that
the connections on the otherhand... I'm currently under the assumption that Apple is to be handling that, but I'll have to dive in and make sure
We do have a spec document on how the JSON you are supposed to be sending through my API should be formatted. A lot of your "it's throwing an error, what do I do?" messages could be resolved by taking 5 minutes to review the spec and making sure your response is conforming.
Working software over comprehensive documentation
This sprint I finally have some Prometheus time planned after all the shit that had higher prio, now that we have a new dev on the team. So I'm looking at etcd for service discovery so Prometheus can find services to scrape metrics from.
The Go client lib for etcd is quite excellent. Wrote an etcd announcer in like 90 lines with all the features I'll need, and just got done with an etcd watcher that monitors etcd for updates in another 90 lines - really simple stuff once I got the hang of etcd concepts.
Once I have those polished a bit more I'll start adding the announcer to services, and write a Prometheus exporter for the watcher that grabs all announced services from etcd and writes to a JSON file that Prometheus monitors to find scrape targets.
It's what we have, so that's what we're using.
I did however do the equivalent packages for Consul like six months ago. We'll switch at some point.
if I do something like ab -n 1000 -c 20 http://127.0.0.1:1337/my/page/
then I can slowly creep up the concurrency to the exact breaking point... but it handles 20 simultaneous requests with ease, and somehow my unit test is exceeding that
on the sunny side, this demonstrates that it is probably also an issue in production, but I haven't noticed it because I have Cores For Days in production, and the limitations of cell connections provide a nice artificial throttle
Which works so well when you need to scale up the number of developers or hand off a project to someone else...
(I'm experiencing this now, and it is a right pain in the ass)
It's a "prefer", not "don't do".
Unfortunately, there's a pretty wide gap between "basic documentation" and "system level understanding sufficient to make deep changes to system functionality"
Ooo, ooo, what do I win?
an entire dollar! the mystery is how I am managing to violate it. the iOS libs have concurrency and max-socket settings, all of which I've set to try and prevent this
and yet, it continues to go nuts.
ThingVM thingVM { get; set; } ... Visibility="{Binding thingVM.showStuff,Converter={StaticResource BoolToVisConverter} }" <!-- the converter is set up elsewhere -->then please tell me that I need to make thingVM public, so I don't burn two hours trying to debug the awfulness that is XAML bindings and wondering why stuff isn't showing.
I wouldn't mind quite so much if this wasn't exactly the same problem that I wasted two hours on yesterday. You'd think I'd remember, but no.
Oi! Ab has never actually worked on Apple. We swapped to httperf because of unhappy hipsters saying how "make stress" fucks up on anything non-linux. Then decided this is shitty too, and setup actual stress testing with log replaying. That was the first thing that actually felt useful.
Can I talk about how much I hate the brave API future? A lot of folks think having an API checks the data availability box, but don't care if it doesn't have a good dataset or isn't performant. So frustrating.
On one hand, yes absolutely. On the other hand, does your spec have some inane bullshit that is easy to miss? Had a contractor writing a module for our stuff at one point, connecting to a third party API and kept getting error after error. Data was submitted as JSON, and at the top of the spec sheet it said this. And then right before all the examples, about 10 paragraphs of corporate BS later, there was a single line that said "All JSON data should be formatted as a single string with |'s separating the calls and values."
So instead of say, having:
data = { call: 'Test', info: 'This is a test call', moreInfo: 'Still just a test call' }You were supposed to do:
data = "{call: 'Test' | info: 'This is a test call' | moreInfo: 'Still just a test call'}"Which is just like...what in the ever living fuck?
I pop into the programming thread for 5 minutes and I'm already dry heaving, thanks @Mvrck
There just aren't enough stabbing knives in the world for fuckery like this.
http://steamcommunity.com/id/pablocampy
...this is where I start looking for guilty fingers to break.
Technically JSON.