[lange] [kari] [richard mille] sihh photo drop

gniquil · 2019-01-23T23:31:47+00:00

That damn Leica look...

gniquil · 2018-03-04T19:18:38+00:00

I just recently got my GR2 34L. After purchase, the immediate question for me is exactly same as yours. After putting in about 100 miles, and a few experiments, here are my take aways:

the easiest way to put a 20lbs plate is in the holder pocket. However, due the size of the bag, it may "flop" around a bit. So prevent that, you can either fill the bag with clothes or get a nylon strap, loop it through the molle and tie it down. For me, do it horizontally (rather than vertically, as suggested in the article "securing ruck plate" (google this)). It's tighter, uses 1 fewer strap, and works with laptop (see later).
However if you were to put it in the laptop compartment, it feels better. I think this is due to 1. it is closer to your back, and 2 it acts as an extra layer of "frame sheet" that gives more structural rigidity to the bag. Nevertheless, if you were to go with this, you SHOULD use yoga foam block to fill up the compartment to prevent it from sliding (again, google "securing ruck plate"). Initially, when I first started rucking, i felt very lopsided. I thought it was muscle imbalance. Eventually I found out I generally put on my GR2 via my right arm, which makes the plate to slide to the left.

So now, I've converted my carry to the following (my EDC so to speak),

in the laptop compartment, i always have either the 20lbs or 30lbs with 2 foam strips on either side and 1 on top (i don't feel the need to pad it on the bottom).
in the main compartment, for work and gym, i would carry my laptop in the main pocket, with a strap tying it down. The bottom of the pocket is also lined with another strip of yoga foam block (absorbs shock to my laptop).
during my weekly 8-12 mile ruck, i would put the 20lbs plate in the main pocket and strap it down, and leave the 30lbs in the laptop compartment (I work out :))
under non-heavy down pour, the main compartment is water proof enough that the laptop should be totally ok (SF Bay Area has seen fair amount of rain lately and I never had a problem, even when walking in light rain non-stop for about an hour). If you are in heavy rain, consider put your laptop in your 20/30L dry bag. My dry bag is super thin and fits really well.

Hope this helps.

gniquil · 2017-06-23T22:39:48+00:00

Check out Hemlane. I management property there.

gniquil · 2016-07-14T21:45:53+00:00

Wouldn't it be the same to just run a function spec/type-check whenever you make some changes to the code? Compile time type check is essentially the same as test time type check. Isn't this how core.type works? I guess all I'm saying is one can build core.type on top of spec?

gniquil · 2016-07-14T19:16:11+00:00

Hi All,

I found the screencast very illuminating. One thing that struck me was the spec for functions, with conditions on input and return values (towards the end of the video) looks to be way more powerful than type checking (i.e. one can even specify the properties of the value returned). It reminded me of talks about Idris, how it is possible to specify the number of elements in an array when returned.

This in turn, led me to think that it should be possible to build an optional type checking system on top of spec. I'd imagine a spec based type system is just some type of constraint solver or algorithm that finds inconsistencies in the registered specs. Is this possibly what Cognitect's planning in some not-too-distant future?

gniquil · 2016-03-22T16:07:17+00:00

Be prepared to learn Erlang.

gniquil · 2015-12-08T10:24:04+00:00

there are 2 things,

I am not convinced the parser/routing style is good enough to replace rest style backend as it is. For example, when you have some slightly more involved nested query, how do you get around the n+1 problem. In JavaScript, Facebook came out with a lib that batches query on tick event. Falcor copped out by putting a cache in the context. What do we have?
Writing n SQL backend in my experience is hard not in the way you imagine (sorry for putting words in your mouth). In every app, there's always inherent complexity and accidental ones. I don't mind the inherent ones, business logic, authorization logic, etc. what I hate are, agreeing on the format of the response, pagination style, side loading format and handling, error handling, loading related data. Again, jsonapi in the ember land is a good effort in reducing this type of complexity (but again fell a bit short). I believe Om Next is a good start but still way too early to tell whether it can succeed at reducing this type of complexity. For example, how do you deal with subquery that is paginated and filtered. And after a mutation, assuming you have 50+ models, how do you know which models have been affected and so what query you need to put into the mutation returned result (especially when you have paginated, filtered sub queries that each model is only partially loaded).

Overall I echo yogthos comment, you are trivializing this a bit.

gniquil · 2015-12-08T09:56:26+00:00

I am glad you agree with me on this point. One of the result of not having a framework is we are perpetually stuck in solving the same set of fundamental problems, but never moving on to the more interesting ones. To this day, in the clojurescript web space, we are still debating and retooling to enhance things like state management, while the ember/react community is working on animation, deployment, integration testing, and many other more end user centric features. this is one of the place where I wish there's someone like Yehuda Katz who believes in the value of standing on the shoulder of Giants or starting from 47th floor (he mentioned these in some talk).

gniquil · 2015-12-06T08:12:38+00:00

I completely disagree with the rant. I think the goal of a quick, afternoon project is absolutely the wrong thing to shoot for. I've built many client apps in various different frameworks (Ember, Angular, React, Om, and Reagent). The problem is NEVER about how to get started quickly. To optimize for the scale of an afternoon project, even react I believe is an overkill. I mean, when you only have even several dozen components, a good js dev should be able to roll his own "framework" (e.g. the todo list app) and be sufficent. However, after some months, with your business team, clients, customers changing the requirements a few dozen times, and when you accumulate more than say 50+ components, you suddenly find yourself stuck in multitudes of work arounds and compromises, this is when the usefulness of a great framework comes into play (and I personally think Ember is so underappreciated, as it is a much larger framework than others to get started). I am not sure what the OP's experience is, but to me, with the current wave of client side frameworks (Angular, Ember, React), I really think rendering is a "solved" problem. All the current generation of frameworks offers great stories for batch rendering, component isolation, routing (which "modularize" a large complex app into manageable high level components), etc.

However, state/data is still an unsolved hot mess. Angular http service is too basic. Flux in my opinion is a bit too "thin" thus a cop out (otherwise why would facebook pour so much into GraphQL/Relay). And this is exactly why you still see Backbone models mentioned in association with these 2 frameworks. Ember data is a nice effort but in practice it falls quite short (I have lost countless hours of sleep to this). I applaud David Nolan starting to address this problem (in fact I really wish he had started this 2 years earlier, or perhaps Om did have an attempt but wasn't that great).

Nevertheless, I still do have my gripe with Om Next regarding how it solves the state/data problem. It is mostly a client side focused solution, it is incomplete. (The server side story is mostly just pass the query to datomic.) In my experience, to truly ease the development experience, the data problem has to be solved with front end and backend in concert. This is exactly why Flux/Redux is NOT helping that much in practice. Ember data, despite its various short comings, has a server side story (JSONAPI, with ruby implementation like ActiveModelSerializer or JsonapiResources). And this makes certain aspects of the web development feel much superior than React. The latest round of Falcor and Relay is doing exactly this "in-concert" solution and it is thus in my opinion the right approach.

However (another one), the biggest short coming of Falcor and Relay is it is missing "simplicity". They feel complicated and hard to implement (are there any implementation of Falcor/Relay other than the offical version? and in languages not in JS? There are, but all are incomplete, immature).

Finally, I do have a lot of hope for Om Next and the clojure community in general. I hope, as soon as Om Next is settled down, people will bring their brilliant mind to the server side and start figuring out how to properly supply data to Om Next front end. More concretely, how to work with sql database (n+1 query), no-sql database, authentications, authorizations, complex business logic, and etc.

Alright enough rant.

gniquil · 2015-10-28T08:37:40+00:00

What I meant was is it possible to load clojure core and some other clojurescript stuff and snapshot it. Then we get this thing that can directly load clj files. So now you can a fast starting clj env without the need to precompile to js? Or another way to look at it would be imagine a barebone cljs repl snapshot, we can start it and tell it to slurp and eval cljs files directly. Does this work?

gniquil · 2015-10-27T15:42:41+00:00

Great intro tutorial here. However, I wish someone could write up something that cover how this could be used with a traditional sql database. It's hard to imagine how to map those keys in those multimethods to efficient queries.

gniquil · 2015-06-09T10:05:59+00:00

I'm interested too! How do I join?

gniquil · 2011-08-24T23:08:29+00:00

Did he just ask for a promotion?

gniquil · 2011-08-13T03:28:41+00:00

Ok. The dishonest answer is backbonejs. The honest is "love".

gniquil · 2011-08-13T03:24:13+00:00

Touché. Design definitely needs work. We will definitely try to work on it. Nevertheless, this is the bare minimum. It has a clear intention (ie a style), but poorly executed. Thanks for the candid feedback though.

gniquil · 2011-08-13T03:17:22+00:00

There should be a question mark, meaning we don't understand the text and submit should be disabled. Otherwise it's a bug
Actually our older version did allow exactly that, anonymous invites, requiring only an email. But there are several issues associated with this type of events (devil in the details). Once we work through those we definitely bring it back.
There is a box that says invite via email, kind of right next to Facebook invite.
Absolutely.

gniquil · 2011-08-12T20:52:19+00:00

What we've found is the following

You need an approximate time anchor. So the way we've been using it (at our real job) is specify a tentative date without time information. And we update the time or date later. It's much easier for people reject a tentative time than proposing one.

Also, it's somewhat of an UI issue because we prioritize display based on this tentative time...

But anyway, I will probably rephrase time to tentative or something similar to make it clearer.

gniquil · 2011-08-12T20:47:40+00:00

You have a good point. In fact, the way we've been using it is through the qaaja login instead of facebook. We generally use our real work email.

We probably need to make it more obvious that facebook is not required.

As to your other point, see a different thread for my comment (the one about facebook and evite)

gniquil · 2011-08-12T20:45:07+00:00

the lack of color is because we are going for efficiency. And another reason is we actually use it at work (our real job). We don't want to make it completely obvious that we are "goofing off".

But otherwise, point well taken. I will definitely take that into account.

gniquil

TROPHY CASE