This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (76)
- # announcements (7)
- # aws (3)
- # babashka (75)
- # beginners (25)
- # calva (37)
- # cider (9)
- # clara (4)
- # clj-kondo (17)
- # cljsrn (1)
- # clojure (106)
- # clojure-europe (4)
- # clojure-india (2)
- # clojure-italy (12)
- # clojure-nl (27)
- # clojure-spec (33)
- # clojure-uk (20)
- # clojurescript (103)
- # clojutre (3)
- # core-async (1)
- # cryogen (10)
- # cursive (24)
- # datomic (113)
- # dirac (5)
- # emacs (12)
- # events (4)
- # fulcro (64)
- # garden (5)
- # jobs (1)
- # kaocha (5)
- # luminus (2)
- # malli (14)
- # off-topic (53)
- # planck (11)
- # re-frame (9)
- # reagent (16)
- # reitit (26)
- # remote-jobs (2)
- # shadow-cljs (137)
- # spacemacs (34)
it's not the ink absorber, right? because there are pages about servicing that on one's own.
yes, the "ink absorber" ... involves removing cleaning/replacing the pads (which canon doesn't sell) and resetting the counter in the printer.... which appears to be black magic. and certainly not in the manual.
I did try a bunch of different incantations to reset the counter.... just for fun. Turn printer off, hold power, press button three times, press other buttons twice, rub head etc... but to no avail.
Some site sells new firmware so you can reset the counter... Im just not that interested in my printers internal life though....
This is a typical printer dance, https://www.ifixit.com/Answers/View/502878/resetting+my+ink+absorber
my experience with these kinds of printers is that it's been an ongoing arms race of sorts -- basically the manufacturer goes out of its way to make it likely you won't want to go to the trouble of circumventing their efforts to get you to purchase a new printer. usually there are methods documented that work, but the trade-off is your time, energy, and frustration. agree that it is a terrible situation.
I did spend a year of my life working on printer drivers for Windows... so I might have issues to work through...
it is like there is advanced technology used to detect precisely the worst possible moment to have problems. i can't remember a printer i didn't have problems with -- back to dot matrix printers.
Well, canon tech support said the lasers tend to be more reliable... in particular the black and white models... less to go wrong.
lol, i had been thinking i might want to get a laser printer -- once the current one fails. the thing about ink jets that i was unprepared for was that if one does not print often enough, the ink appears to dry and cause problems.
is there any recommend for free software for draw graph to help me write code. sometimes I have to write a feature in a few days, I have to focus on piece by piece. EDIT: I think I found <http://draw.io|draw.io>
@doglooksgood lread has also made good use of <http://draw.io|draw.io> -- i've used it a bit too. also not sure what you are looking for, but if you take a look at: <https://clojurians.slack.com/archives/C03S1KBA2/p1575636577175000> and read up through alexmiller's responses, there are some suggestions that might be relevant.
what should I write first when starting a big project or library? is having a complete design very important before start coding the first line?
That only works when you 100% know your domain and the problem you want to solve. The catch is, you almost never get to those 100%. No matter how robust the design on paper, you make changes to it during development.
For example, If I want to write a library, I get how the API looks like and what effect it will make at the beginning. they are begin and end. But there may be so many internal states, when doing a long time work, It's pretty hard to always get right in the middle.
Yep. You'll get there with more experience. Even if you planning everything in advance is the way to go in your case, you're probably not able to plan it good enough since you're asking this question. Hence, just plan till you start to be unsure of something, then start implementing. Rinse, repeat.
It's mostly the law of diminishing returns, the more precise you plan the less you get out of it. So having an open plan that can adapt as you gain knowledge of the domain has some nice benefits, but going overboard and planning each specific detail and then having to change everything when you find out that something isn't what you expected isn't as nice.
But also start small - don't try to solve a huge problem right away. Even if you have to solve something big, try to split it into small chunks.
@doglooksgood there are so many different ways of approaching it. I think the most popular ways are: • Big design up front: take lots of time to think and ponder about the problem, then spend little time actually implementing it • Startup hipster: don't think, just implement, discover things along the way, work your way backwards and forwards, maybe all at once • Re-Implementing until nice: start with the most basic implemention until it just works. Then throw it away, begin from the beginning. Repeat until you got a nice design (The Donald Knuth way [I think?])
I don't think the first one is possible unless the project is fundamentally easy. There's always stuff you didn't think of
Yeah, I'm not saying all of them are optimal or even good. It's just the ways I've seen things being built (where enterprise tends to fall into the first, startups the second and freetime projects the third)
I like to make a minimum viable product and work from there, ideally, although when I do stuff at home I'm more the hipster 😁
I think you have to accept that a large part of "design" is really discovery. You discover along the way what you really need, what works and what doesn't.
You discover by trying things out, either as prototypes that you throw away, or by starting small and iterating.
If it is a feature which will take me about one week to make it just work, how can I make sure I create the correct function signature and use correct shape data? I mean in the middle of project?
for example, considering A -> B -> C -> D. 4 shape of data, I know the beginning A and the end D, but sometimes it's hard to know B and C. I may think something is necessary, but will find it's not later. Or suddenly found I missed something before.
How can I record my work in a pretty readable format, instead of every time I look backward and forward.
every design decision has trade-offs, but no design decision is permanent. Start with a sketch (a literal sketch diagram on a piece of paper, or a sketched solution in code), then look at what you have, and think about the pros and cons of your solution, the assumptions that went into it, and then think about how else you could do it.
Alex Miller's talk from ClojuTRE this year also had some good tips, seems like he and Rich have a great way of using diagrams and spreadsheets to work through these design decisions.
You might also want to look at Architecture Decision Records if you want to keep track of the design decisions you make.
Just don't paralyze yourself by trying to think up a perfect solution from the start. It doesn't exist.
ADRs are great for this, here's an example https://github.com/lambdaisland/metabase-datomic/blob/master/doc/architecture_decision_log.org
I very often end up writing the data literals in a scratch buffer, to see if I like the shape of things. Also, trying to use namespaced keywords has proven to be quite helpful in discovering things that should be split apart.
> Typically people think about design, and they say design is, you know, making this big, involved plan that's going to solve every issue that the system is supposed to address. But I think that's not what you do when you're trying to get a design that's going to survive and live over time. I think, instead, what you want to do is break things apart in such a way that they can be put back together. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/DesignCompositionPerformance.md Personally I find 's recipe for design nicely balanced: make things simple, write things down (like rationale, alternatives, etc). That's about it :)
Ahaha it makes me think about the nature of components overall (this is a bit of another, possibly mostly unrelated tangent). If your smallest reusable component is a brick, then you can make a wall. If your smallest reusable component are legos, you can make pixelated spaceships. If your smallest reusable components are atoms and molecules, you can make anything. The smaller a component is, the less it contributes to an overall combination (you'll need a lot of atoms to get anything made), but the smaller the limits are to what you can express with it, and the more you can reuse it (of course, for that reason, you make the component / abstraction too small and its cumbersome to use in a completely different way, for the same reason its precise but overly difficult to build a sculpture with one grain of sand at a time). Every time you have a piece that is made of components that cannot be broken apart, then when the time comes inevitably that those sub pieces of functionality must be used again, you are forced to write them again. If all your units are these massive chunks that cannot be broken down, then they are the bottleneck of reuse; any reuse will have to be in pieces bigger than them. You can't make a bucket from a log if you can't cut it, although it may fit into a log cabin. Of course, if components are abstraction -- the act of taking something and cutting out a smaller shape, you also want clean shapes that can be stacked together -- like bricks. Some of the more overly specific abstractions are more like cutting out puzzle-piece shaped bricks, that are technically components but ones that only fit with another very specific puzzle shaped component, and so now you have a hardly reusable abstraction that has taken one easy enough to understand idea and has turned it into two haphazardly shaped pieces whose shapes are themselves an entirely new thing to learn (hence you get WET - write everything twice). They call them puzzles for a reason. ... I have no idea how I always get off on these tangents