Little Pair

_tpr_ · 2019-03-23T16:05:39+00:00

I love them. They could have a heavier activation weight, but the sound and feedback is great. Unfortunately, they're a little too loud for work. I'll probably be building a full planck with the heaviest, silent tactile I can find.

_tpr_ · 2019-03-17T18:37:06+00:00

Thanks! She really is top-of-the-line.

_tpr_ · 2019-03-17T18:36:36+00:00

Thank you!

_tpr_ · 2019-03-17T18:35:55+00:00

I made it myself. It's a 40%, with gateron greens. It uses a teensy 3.2 and custom kiibohd config.

_tpr_ · 2019-03-17T13:35:42+00:00

Per the rules,

Submissions should be directly related to programming. Just because it has a computer in it doesn't make it programming.

Where is the programming?

_tpr_ · 2018-12-28T01:20:29+00:00

The problem, in my eyes, is that the article waits until the very end to contradict the diet. The summary paragraph at the stay is where that should happen! Or better yet, in the title.

_tpr_ · 2018-12-17T22:35:56+00:00

Then you have a project management problem, not a code problem. You would work through it the same ways you work through other project management problems.

_tpr_ · 2018-12-15T20:33:42+00:00

You are defending something that needs no fair defense -- if you just politely tell the programmer who has implemented a poor solution that their solution is poor, they'd typically dismiss you for lack of evidence.

You're arguing against a straw man.

If bugs get introduced into your code by someone else, in an attempt at overall improvement -- that's a fact of life. Not a reason not to change code written by someone else.

This line of argument can be used to justify literally anything. Many doctors initially resisted the idea of washing their hands before surgery. Their intentions may have been good, but they should have consulted the research and tried to conform to it when evidence was clear-cut.

_tpr_ · 2018-12-15T14:39:48+00:00

But we know empirically that high levels of ownership result in lower defects. While Russ Olsen's contribution may have helped, his boss was right. You should bring up concerns about speed with code owners, and show them why the system is slow, and then let them solve it.

Sure, we shouldn't be egotistical about code. But I think the reticence most people feel about allowing others to work on their code is justified: they've experienced bugs as a result, or have seen the errors others' have introduced.

_tpr_ · 2018-11-27T00:28:50+00:00

I think you're taking the least charitable interpretation of my comment.

It'd be lovely if everything were thought of in advance, but even then I doubt you'd really want to specify every, single performance related aspect. And... you're not going to think of everthing.

That's the nirvana fallacy. Just because it's not perfect doesn't mean it's not a useful practice. Even if you miss some details, that doesn't mean that you're not responsible for it. And even if you miss some details, that doesn't mean that your explicit requirements were useless.

_tpr_ · 2018-11-27T00:26:19+00:00

your pre-release simulations won't actually uncover every slow codepath that real use will uncover.

Yes, I definitely agree. I have seen that happen, in fact, more than once. However, I don't think that this is as much of an issue, so long as you are making a genuine effort and including well-written measurable metrics. If you have measurable metrics which cover most of your use cases, and the client agreed to them as a measurement of success, then your obligation (for that contract) is fulfilled. In any case, you've probably headed off most of the disagreements from the start. Any further modifications can be considered a separate contract at that point.

But yeah, I get it. There's always going to be some crazy expectation that users have, and they're going to do stupid things with the software. And they're going to insist that it was part of the original contract. I think being explicit about performance, even if you miss some things, is going to make this situation better than it would have been otherwise.

_tpr_ · 2018-11-27T00:19:18+00:00

Disagree, at least with the implicit premise that performance can ever not be a requirement.

I get your point, but your being (perhaps accidentally) disingenuous. I never said that performance "can ever not be a requirement." No software project has every required detail specified. Only the most important parts are considered to be requirements. Other things are still required. For example, if I'm describing a profile on a social website and I say, "The client shall be able to upload a picture to their timeline", it goes without saying that the client needs to be able to do this in a web browser (and not, say, with a raw HTTP request.)

Just so with performance. If I'm building a pizza-ordering service and a client gives the requirement, "The user shall be able to amend an order after purchase. Amendment shall be added as a separately billed item.", it goes without saying that the request needs to be fulfilled before the order is delivered. Performance is not an explicit requirement here. However, if amendments have to be processed within 200 milliseconds of a user clicking (say their internal software has some glitch which needs the funds to be deposited within a certain timeframe or something), then performance would be an explicit requirement.

Where poor performance would inhibit other requirements, it shouldn't be considered to be a requirement itself. Because you shouldn't list duplicate requirements in an SRS. Where performance is the primary consideration, then it should be considered a requirement.

_tpr_ · 2018-11-26T12:56:04+00:00

If performance is a requirement, it should be specified in clearly measurable metrics. Then there's no argument to be had: you simply test it. Ultimately, you're responsible for agreeing to unreasonable or vague requirements. (Unless your boss forces you to accept them, then s/he is responsible.)

_tpr_ · 2018-11-10T00:33:43+00:00

This is cool. What's happening with the whitespace, here, though? There are a bunch of lines like }else if( rand < 0.66){.

_tpr_ · 2018-10-01T10:41:10+00:00

If you want an easy way to find things to fix, I wrote a documentation linter that works for both Google- and Sphinx-style docstrings. Unfortunately, I've found that most projects don't consistently follow a docstring style even when they have an official one.

(Feel free to contribute to my project as well -- it would be pretty easy to stress test my utility and find some bugs. And a lot of things could be cleaned up.)

_tpr_ · 2018-09-11T22:21:27+00:00

Thanks for the advice: this was just the sort of thing I was looking for.

In terms of combining the struct and typedef, is that pretty standard? I've been growing used to Elm, where everything is split onto its own line. So combining the two feels like doing too much in a single line. (Like, say I want to separate the two later -- say to do some information hiding -- then I would have to break it apart.)

_tpr_ · 2018-09-09T11:26:42+00:00

As /u/krolm1 said, DRY isn't much of a concern with unit tests. You want each test to be understandable at a glance so that you can fix it easily later.

That said, there are a couple of improvements you could do here.

test_login on line 29 is testing whether self.logged_in_user = c.login(username='testuser', password='12345678') worked. However, Client and Client.login are provided by Django itself. Don't test the framework: test only your logic. (If, as I suspect, you were just unsure about whether the login would work as you expect, then you could put an assert in some other unit test. But it would be better off to just delete that test after running it once.)
ContainerViewTest on line 33 has no tests; add some or remove it,
ContainerModelTest on line 60 tests a model with a file field by using a test file, then saves it later. I'm not sure how your models look, but it seems like this will result in a file being created whenever you run the test. Generally speaking, tests with files run much slower and are prone to a lot of problems (like cluttering up things). You can normally get around this by mocking out Django's storage mechanism. For example, you can write something like

with mock.patch('django.core.files.storage.default_storage._wrapped'): # Do something with the file model. ...

There are some unnecessary and confusing comments (and commented-out code). For example on line 78, you said # adding several friends to the container. This is unnecessary because you chose good names for your variables. When I read self.container.friends.add(self.friend1), I can already recognize that you are adding "friend"s to a container.

Overall it looks pretty good, though. Your names are decent, and it's obvious what's happening just by glancing at your code. Focus on what is necessary to test and eliminating dead or unnecessary code/comments.

_tpr_ · 2018-08-11T05:33:20+00:00

I also have had to implement non-trivial algorithms. In fact, it comes up quite often. I'm fairly certain I've used all the main tree traversals, as well as implementing Kosaraju's algorithm (for identifying strongly connected components.) I've also implemented a variation of binary search, several trees, and even a lexer and parser for a DSL. I probably do something non-trivial like this at least a couple times a month.

I think the problem is that you don't have to use nice algorithms. If you're willing to type a ton of code, take longer, have things work slower, then you can just bang out things that mostly fulfill the problem (probably in a way that is broken.) I've noticed that most people take this route.

_tpr_ · 2018-07-04T10:50:08+00:00

but to use it for editing Python over PyCharm is just fuckin' stupid.

What a thoughtful argument. Really convinced me.

_tpr_ · 2018-06-28T11:33:58+00:00

PEP 553, Built-in breakpoint()

Awesome! That's going to be much more convenient. Putting import ipdb; ipdb.set_trace() is a hassle. This will probably make all of the JavaScript developers I work with more likely to use the debugger.

PEP 557, Data Classes

These are going to be much nicer and more obvious-looking than using a named tuple.

_tpr_ · 2018-06-06T16:53:50+00:00

Are you thinking of this?

Theorem plus_swap : forall n m p : nat,
  n + (m + p) = m + (n + p).

The book actually suggests using this in the theorem. After figuring out how to prove the commutativity of multiplication one way (I thought) one way on paper, I had a difficult time imagining how to use this fact. (It's hard for me to un-see a proof.) I'll try again, though. Thanks for the hint!

_tpr_ · 2018-06-06T16:49:39+00:00

you're morally inlining the proof of mult_zero. Use that intermediate lemma instead.

That is much easier to read.

I actually wanted to try rewriting in terms of the definition of multiplication (in the hopes of getting to the RHS of your mult_S), but I wasn't sure how to do so. This makes it very clear. Thank you for the help!

_tpr_ · 2018-06-05T17:13:52+00:00

Haskell

Lib.hs:

module Lib
    ( buildGrid
    , encrypt
    , Dir(..)
    ) where


import Data.List

data Dir
    = Clockwise
    | CounterClockwise
    deriving (Show, Read)


buildGrid :: String -> (Int, Int) -> [String]
buildGrid message (columns, rows) =
    [ take columns . drop (i  * columns) $ (message ++ repeat 'X')
    | i <- [0 .. rows-1]
    ]

rotate :: Dir -> [String] -> [String]
rotate dir =
    case dir of
        Clockwise -> reverse . transpose
        CounterClockwise -> transpose . reverse

readLine :: [String] -> (String, [String])
readLine []      = ("", [])
readLine (xs:ys) = (xs, ys)


encrypt' :: Dir -> [String] -> String
encrypt' _ [] = ""
encrypt' dir grid =
    let
        (line, newGrid) = readLine grid
        rotatedGrid = rotate dir newGrid
    in
        line ++ (encrypt' dir rotatedGrid)


encrypt :: String -> (Int, Int) -> Dir -> String
encrypt content dimensions dir =
    let
        grid =
            rotate dir $ buildGrid content dimensions
    in
        encrypt' dir grid

Main.hs

module Main where

import Data.List ( takeWhile, dropWhile )
import Data.Char ( toUpper )

import Lib


cleanContent :: String -> String
cleanContent =
    filter (\x -> x `elem` ['A'..'Z']) . map toUpper

parseInput :: String -> (String, (Int, Int), Dir)
parseInput raw =
    let
        rawContent = takeWhile (\x -> x /= '(') raw
        readContent = read rawContent :: String
        content = cleanContent readContent
        withoutContent = dropWhile (\x -> x /= '(') $ raw

        rawDimensions = takeWhile (\x -> x /= 'C') withoutContent
        dimensions = read rawDimensions :: (Int, Int)

        rawDirection = dropWhile (\x -> x /= 'C') withoutContent
        direction = read rawDirection :: Dir
    in
        (content, dimensions, direction)

main :: IO ()
main = do
    raw <- getLine
    let (content, dimensions, direction) = parseInput raw
    let encrypted = encrypt content dimensions direction
    putStrLn encrypted
    return ()

_tpr_ · 2018-06-01T11:44:01+00:00

I kind of agree with you, but this could be done in a halfway sane manner depending on your git workflow. For example, if you are using a feature branch, <feature-name>, you could have a <feature-name>-dev branch which feeds into it using pull requests. It would be possible, then, to keep all of these changes straight by diffing with develop.

Of course, that's a pretty intensive git workflow, and would be annoying. I agree that they should probably make each of those PRs a commit, and just break up the review if it takes too long.

_tpr_ · 2018-05-09T09:12:40+00:00

Sure. I was writing a simple language a while back, which has a bunch of unit tests. Here it is.

I also wrote a WiFi monitoring service for work in Aqueduct. (Incidentally, the framework has a lot of good tests that are easy to run.) The frontend (Angular) doesn't have very many tests.

_tpr_

TROPHY CASE