2,411,571 events, 1,277,477 push events, 1,902,506 commit messages, 119,480,077 characters
Math. Fuck it
So the math part is doing my head in and I want roads. We want roads. The creeps want roads.
They arrived at my door with pitchforks, i'll give them roads now.
prozedurale_sprachen_next_permutation_algorithmusdesign
holy shit. die beschreibung war sehr irreführend und deswegen etwas schwer. note an mich selbst: verlasse dich nicht zu sehr auf die Beschreibung von anderen.
make the uranium go brr
i dont know if it works but fuck you too idiot because testing isnt my strong suit
Removes a source of ian harddels, keeps mcgruffs bed discription from getting overwritten at roundstart, moves the bed claiming feature to just the dogbed typepath, none of the subtypes, this applies to buckling too (#55158)
Removes a source of ian harddels, keeps mcgruff's bed description from getting overwritten at roundstart, moves the bed claiming feature to just the dogbed typepath, blacklisting subtypes. This applies to buckling too.
This means that a dogbed can only ever belong to one dog. Fuck you. Remake of #54892, github doesn't like force pushes, not sure why
refactored all files to 79 char limit
holy fucking shit my code is dog man
refactor(microservice-lib): IRC-style not fixed-width headers (6)
Explanation: From our perspective, the most mentally challenging part of TCP/IP is getting used to the constraints of blocking I/O operations:
When you go to read a tcp/ip message you must specify how many bytes you are reading; and if that many bytes isn’t available yet, it will block until that many bytes show up (or forever if they never show up).
(Indeed this same dyanamic can be at play in a lot of I/O operations, like reading from STDIN.)
In the example (from the python source code comments?), the server keeps
reading from the client until the client closes the connection (and
recv results in a zero-length bytestring). The client knows exactly
how many bytes to expect from the server because of the contrived
behavior of the “echo” server: the length of the response will always
equal the length of the request.
In the case of client reading the server response, the read operation blocks until all the N bytes are available. The server knows when to stop reading from client because the client closes the connection when it’s done sending.
Our requirements differ from this overly-simple example because A) we want a single client connection to be able to send multiple requests to a server (in sequence), and B) we want the messages (request and response) to be of any arbitrary length, not some length pre-determined.
In the state of things way before this commit (1 or 2 years ago), we
overcame this limitation with the select function. With this function,
you provide a timeout amount and it returns without blocking after that
time is elapsed, even if no new bytes were available.
Upon revisiting this dynamic, we decided that this was a sub-optimal solution because it doesn’t accommodate the possibility of multipart messages; that is, it may be the case that more bytes aren’t available because of network latency, and not because that’s the end of the message. That’s why, this time around, we started thinking about headers:
In the state of things before this commit, we overcame this limitation by using “fixed width headers”: a “header line” was exactly 80 bytes wide, and there was one header line for expressing the “content length” of the “payload” of the message. Provided that clients and servers both employ this API correctly, they could read headers from each other without forever-blocking because they could know it’s safe to request the next 80 bytes from the message (until they reached the end of the headers, which itself was signified by a fixed-width header line that said something like “End of headers” lol).
The really cool part was, this worked. But after discussion with a colleague, we concluded that we could overcome the inelegant clunkiness of fixed-width headers by reading the tcp/ip message byte-by-byte with the assumption that every header line ends in a newline (and that the end of the headers is indicated by a single blank line) (Probably we are reinventing a very small part of HTTP that we read somewhere 24 years ago.)
What’s really really cool is that this worked. The only problem now is that our heavily-mocked tcp/ip connections underwent a lot of strain to be able to accommodate this byte-by-byte reading in a way that wasn’t obscenely wasteful or effectively unusable from the definition side.
(times) 23:42 begin big refactor 00:51 finished DRY encode decode and print hack. begin change how headers are parsed 01:04 ok really about to start coding the new headers parsing thing 01:56 new way of headers is sketched out. but need a rest 10:21 resume. 21 minutes later visual test passing. tests will be annoying. 11:43 finished catching up tests, maybe .
holy fuck/! rewrote chat implementation with websocket ws instead of socketio. Implemented simple realtime document collaboration with sharedb. I'm a god.
More Mushasha, the people said.
My name is Yoshikage Kira. I'm 33 years old. My house is in the northeast section of Morioh, where all the villas are, and I am not married. I work as an employee for the Kame Yu department stores, and I get home every day by 8 PM at the latest. I don't smoke, but I occasionally drink. I'm in bed by 11 PM, and make sure I get eight hours of sleep, no matter what. After having a glass of warm milk and doing about twenty minutes of stretches before going to bed, I usually have no problems sleeping until morning. Just like a baby, I wake up without any fatigue or stress in the morning. I was told there were no issues at my last check-up. I'm trying to explain that I'm a person who wishes to live a very quiet life. I take care not to trouble myself with any enemies, like winning and losing, that would cause me to lose sleep at night. That is how I deal with society, and I know that is what brings me happiness. Although, if I were to fight I wouldn't lose to anyone.
Merge branch 'dev' into dev-mboonstra-feltcutemightbreakeverythinglater
I. HATE. MY. LIFE. Someone else go fix this. FUCK THIS.
Employee HR attrition_project.ipynb_Dynamic20
df_HR is a dataset of IBM employee attrition data. Each row is personal and attrition information of an employee. Our project is focusing on using machine learning to predict attrition. We are also providing interesting findings that people usually don't think of regarding employee attrition.
Important columns in df are:
1-Attrition: Whether employees are still with the company or whether they’ve gone to work somewhere else. 2-Age: 18 to 60 years old 3-Gender: Female or Male 4-Department: Research & Development, Sales, Human Resources. 5-BusinessTravel: Travel_Rarely, Travel_Frequently, Non-Travel. 6-DistanceFromHome: Distance between the company and their home in miles. 7-MonthlyIncome: Employees' numeric monthly income. 8-MaritalStatus: Married, Single, Divorced. 9-Education: 1 'Below College' 2 'College' 3 'Bachelor' 4 'Master' 5 'Doctor'. 10-EducationField: Life Sciences， Medical， Marketing，Technical Degree，Other. 11-EnvironmentSatisfaction: 1 'Low' 2 'Medium' 3 'High' 4 'Very High'. 12-RelationshipSatisfaction: 1 'Low' 2 'Medium' 3 'High' 4 'Very High'. 13-JobInvolvement: 1 'Low' 2 'Medium' 3 'High' 4 'Very High'. 14-JobRole: Sales Executive，Research Science, Laboratory Tec, Manufacturing, Healthcare Rep, etc 15-JobSatisfaction: 1 'Low' 2 'Medium' 3 'High' 4 'Very High'. 16-OverTime: Whether they work overtime or not. 17-NumCompaniesWorked: Number of companies they worked for before joinging IBM. 18-PerformanceRating: 1 'Low' 2 'Good' 3 'Excellent' 4 'Outstanding'. 19-YearsAtCompany: Years they worked for IBM. 20-WorkLifeBalance: 1 'Bad' 2 'Good' 3 'Better' 4 'Best'. 21-YearsSinceLastPromotion: Years passed since their last promotion.
Prepare TodoMVC implementation
First of all, I needed a test framework. Because I like pain I thought I shouldn't start using libraries now and rather implemented my own shitty version of something that looks like mocha when squinting. Because mocha is what I'm used to. Let's see how soon this breaks down. Together with colored output from goheadless and livereload it at least looks fancy.
The list of test cases is taken from [1]. They do provide the test suite - but I'd rather build it myself and learn something. I want to keep the tests themselves close enough to their implementation to be compliant in the end.
[1] https://github.com/tastejs/todomvc/tree/master/tests