erso

I've owned both. Had a ZBoard, have a Boosted Board.

The ZBoard is utter trash compared to the Boosted Board. Build quality, ease of operation, sound of operation, ride quality are all far superior on the Boosted Board.

For homebrew:

    cd $(brew --repository)
    git remote add krishicks git@github.com:krishicks/homebrew.git
    git fetch krishicks bash
    git checkout krishicks/bash
    brew upgrade bash

  An interesting way to solve the issue is to hide the bar when scrolling down, and show it when scrolling up.

I typically stick to reading around the top of my device, and occasionally I want to re-read something I just read. Instead of just getting to re-read the hidden lines, I have to continue scrolling while stupid chrome or a fixed bar appears, and then finally lets me scroll the content.

It's probably the case that a lot of people love this, but I hate it. If I want to see the browser chrome or navigational elements, I'm happy to tap the top of the window to scroll me there. I don't want the browser trying to figure out what I want to do based purely on scrolling.

I agree with losing the hamburger buttons, but the Facebook example is terrible:

http://tctechcrunch2011.files.wordpress.com/2014/05/facebook...

  Left: Facebook’s old hamburger button navigation. Right: The new tab bar style

A well-written, real-world review of Glass. I enjoyed it.

I'm curious to know if, were the tweets to be used, they would also have to prove it was he that made them. Sure, they're from his account, but would that hold up in court? See: the many celebrities who have people tweet on their behalf with their (the celebrities') account.

It was at some point in the past. I recently booted up an old machine of mine that's running Chrome 7.0.517.41 beta, and the option is both there and ticked by default.

New York

Junior/Senior developers at DaisyBill

We're looking for 1-2 developers who are experienced with Ruby, Rails, and JavaScript. We don't have a designer, so having an eye towards good UX/UI is a plus.

We're also looking for someone at the CTO level.

DaisyBill is located at 34 W 15th Street in Manhattan. We're a SaaS vendor serving the workers' compensation e-billing market.

Workers' comp is a vastly underserved part of the medical e-billing trade which has been a struggle for all parties involved: the injured worker, the practice that treats the injured worker, and the insurance companies that handle the claims/bills. Electronic billing aims to make the situation better.

DaisyBill manages the entire billing process, both generating and sending the bill electronically and managing the responses about the status of the bill, including when it was paid and how much. As a result of using DaisyBill, practices are paid more quickly and accurately than when they submit bills via paper/snail mail. We're talking 15 days instead of 60, 90, or more, if at all. This makes practices more likely to take on injured workers as patients, an obvious benefit for all parties.

You can read more about our service offering at www.daisybill.com.

The stack we currently run is Rails 3 on Heroku.

We use Git for source control and use Macs for development. We develop in an agile manner in the style of ThoughtWorks and Pivotal Labs, using Pivotal Tracker. We like our code to have tests, and as such we have an extensive suite covering the Ruby, Rails, and JavaScript code on the site.

Please send all inquiries to jobs@daisybill.com.

I'm not sure I understand the point of the post.

I like the idea of submittal checklists, indeed this is a part of our business that maps very literally to what our users need to do: complete a list of tasks before submitting an electronic bill.

However, equating submittal checklists to something including stand ups seems weird to me. Would you really have a checklist saying "Did stand up meeting today." and if so, why?

The point of a checklist is to put knowledge of what needs to be done for a task in the world instead of keeping it in the head (I've borrowed this idea from The Design of Everyday Things). Checklists are for complicated things, like the aircraft checklist you mention, that require every step to be checked otherwise people may die.

I'm a fan of small checklists for software development that determine when a user story is completed. In Tracker there's tasks you can add to a story that can be used as acceptance criteria, for example.

But what good is a communication checklist? Is it really a desire to have a checklist that includes items such as "had standup meeting?" And if so, why?

DaisyBill - 34 W 15th Street, NYC - http://www.daisybill.com

Senior Ruby/Rails/JS developer, full-time and local only

DaisyBill does workers' compensation e-billing for the state of California.

We're a small company with 5 people in NYC and 2 in California.

Workers' Comp is a vastly underserved part of the medical billing trade which has been a struggle for all parties involved: the injured worker, the practice that performs services on the injured worker, and the insurance companies that handle the claims/bills. Electronic billing aims to make the situation better.

Effective October 18, 2012, all claims administrators (insurance companies, self-insured employers, et al) for California workers compensation claims are required to be able to receive bills electronically.

DaisyBill is the facilitator for practices to take advantage of this new law, allowing them to enter in the information about services rendered, seeing both what they should charge for the services and what they should expect to be paid (as these are not always the same). DaisyBill manages the entire billing process, both sending the bill electronically and managing the responses about the status of the bill, including when it was paid and how much. As a result of using DaisyBill, practices are paid more quickly and accurately than when they submit bills via paper/snail mail. We're talking 15 days instead of 60, 90, or more. This makes practices more likely to take on injured workers as patients, an obvious benefit for all parties.

--

We're looking for someone to help us with a new product/revenue stream we're going to be developing shortly. This product is a new fee calculator as the current one is expiring after the new year. We're also going to be integrating with third party billers that are currently unable to submit workers comp bills electronically. There is no shortage of work to be done and there is a lot of money to be made.

I'm Kris, the CTO and sole developer at DaisyBill. Previously I was at ThoughtWorks, then Pivotal Labs. I decided to get out of consulting and into a product company because I wanted to own the product I was working on. DaisyBill is the only company out of many I considered that has a solid business plan with an intent to make a lot of money and do some good in the process.

I'm looking for a senior developer that is experienced with Ruby, Rails, and JavaScript. The stack we currently run is Rails 3.2/PostgreSQL 9.2 on Heroku. I'd like to rewrite the site using AngularJS at some point in the near future, so Angular experience is a plus. We also don't have a designer, so having an eye towards good UX/UI is also a plus. We use Git and I'd expect any new hire to either already know Git quite well or be unafraid of it and be able to be brought up to speed quickly. I currently develop on an iMac with MacVim, and most people in the office use a standing desk.

You would be pairing reasonably regularly for the first few weeks but be expected to work independently not long after joining, asking questions as necessary. We also do a loose form of TDD: I typically like to sketch out an idea before trying to bake it in with tests. I also don't test every line of code. I believe in being pragmatic about testing. We use RSpec and Jasmine.

I do interviews similarly to the way they're done at Pivotal: After chatting about what you're looking for in a position I'd have you come in and pair on some code. I care a lot about the interview process allowing the candidate to suss out whether the work environment and the actual work is what they're interested in. I don't do conference room whiteboard programming.

I don't have a degree, and I don't expect you to have one, either. I don't necessarily care about how long you've been a developer, either. I care about the quality of your code today and your approach to solving problems. If you're capable and can show it, I'm interested.

You may reach me at khicks@daisybill.com.

Cheers.

Note to Pixelmator folks:

  Turn good-looking pictures into spectacular.

  Turn good-looking pictures into spectacular images.

I've used only evasi0n on iOS 6.

Setting animation speed is also available for jailbroken iOS devices, if anyone's interested. The Cydia app is called FakeClockUp. I like setting it to 1.4x.

I found this article completely unreadable due to Helvetica Neue Light body font. The Helvetica Neue Ultra Light header is also ridiculously unreadable.

I found this post entirely unreadable due to its usage of Helvetica Neue Light #777 body font.

I've noticed this effect also, and across a number of apps, on both an iPad 4 and an iPad mini. It's most obvious on the mini due to the low pixel density on the iPad mini.

I can't read the mini in portrait mode mostly because I haven't found a font+size combo that I find acceptable.

Perhaps the first line of the post would have, then?

  In one of the most shocking videos I’ve seen
  since launching this blog six years ago...

Sorry, but what did you expect?

  California Police Arrest Man for Video Recording, then Kill his Dog

You consider Helvetica Neue body text in font-weight: 300 and color: #777 to be easy to read?

Jesus. I must be getting old or something.

I feel like this trend is a new kind of sickness plaguing web design everywhere. Even The Verge does it in articles: http://www.theverge.com/2013/6/17/4436332/macbook-air-review...

I'm not sure I understand.

If I'm making a change to some code and someone else makes a different change to it and pushes their change to origin before me, I do a rebase and see that they made the change, fix my commit (which is broken at that point in time), resolving the merge conflict, and continue on.

Instead of seeing some changes that have no basis in reality because they were fixed as part of resolving the conflict when doing the merge, you see only their changes applied on top of the correct state of the world, which gives you a clearer idea of what changes they made.

You can still get logical chunks of work with a rebase strategy: you simply rebase on top of the remote and then do a non-fast forward merge, via merge --no-ff.

What you've said here is at best disingenuous, at worst outright wrong and confusing.

The changing of the SHA per se has nothing to do with why a conflict might arise. The conflict may arise because a particular commit could not cleanly be applied to the new base. The contents of the commit need not even change, which you can verify by looking at the actual contents of the commit, meaning the blobs that it contains. The blobs may stay the same (and indeed, will unless there's a conflict during the rebase), while the SHA changes.

> Part of the SHA contains the SHA of the commit before it.

This is incorrect.

A commit SHA has a tree SHA and a parent SHA associated with it. It's the parent SHA (the base of the commit) that changes when you rebase, which is a cascading change that continues down the tree in order as commits are applied. The SHA only changes because the SHA is a hash of the contents of the changeset and the time at which the commit was created.

You can see the commits along with their parent and tree hashes by doing `git log --format=raw`.

> Never rebase if you've pushed the commits to a central repo because git will detect conflicts of the changes.

This is also incorrect (or at least badly worded and disingenuous).

Git only knows that the changes you're attempting to push will cause you to lose data, which it says explicitly when you rebase a commit that's been pushed to the remote.

You should of course avoid rebasing commits that are on the remote unless you are the sole committer on the remote branch (meaning nobody else is pulling from that branch). You have to force push the branch when you do so, which is fine when you're the only person looking at it and disastrous when not.

Except this idea of the context in which you wrote the code doesn't actually matter to anyone.

More likely you're going to piss off everyone that has to deal with your merge strategy because your commits that couldn't be merged into master are broken, having been fixed as part of the merge commit(s).

Such commits:

* Aren't able to be bisected (they're broken, remember?)

* Aren't able to be blamed (the collective merge commits and the actual commits have to be considered at the same time)

* Aren't able to be rebased later when you decide, actually, this merging shit is ridiculous (the -p option to rebase is dangerous and doesn't always work the way you think it will)

* Aren't able to be traversed cleanly in a log because they're probably split up with merges of master into your branch all over, because hey, you wanted to stay up to date.

* Basically aren't understandable by anyone, including you.

Being that it's not 2011 anymore (sorry, what?), you should learn how to use Git properly, understand what effects your workflow have both to you and to those that read your code (including you!), and those that choose to use Git's tools.

I once had a situation on a client project while at Pivotal where a guy had been working on a branch for 2 months, continuously merging master into his branch. It was a shitshow. He had 45 commits of his own plus 10-15 merge commits from origin/master. Doing a git log of that nonsense was basically impossible to read, impossible to code review (the client's process at the time), and when merged back into master would have been the most crazy ass log --graph I can imagine (because everyone else was doing similar nonsense). We're talking a 10-pair dev team all merging origin/master into their local master. The log was unreadable, unusable, not to be understood by anyone.

Luckily I was able to remove all the merge commits via the 2-argument form of rebase --onto, (http://krishicks.com/blog/2012/05/28/git-rebase-onto/) which then gave him the freedom to squash, reorder, fixup, and split his commits as he felt necessary to maintain his and everyone else's sanity. In the end he filtered it down to something like 20 very clean, green commits that could be reviewed by another person and understood, and rebased on top of origin/master.

If you have some commits:

    A-B-C-D-E-F-G

git branch topicA

    A-B-C-D-E-F-G (master)
    A-B-C-D-E-F-G (topicA)

    A-B (master)
    A-B-C-D-E-F-G (topicA)

    A-B-----------H (master)
       \         /
        C-D-E-F-G (topicA)

I would ignore everything base698 says below.

In this case, you have a merge commit from a branch on to master, which would look like:

    A-B(master)----F (merge commit)
        \         /
         C-D-----E (topicA)

git rebase --onto origin/master C~1 E

Which would take C's old base, C~1 (B), and replace it with origin/master, but only up to E.

Or, if you still had the branch around that you merged into master (which you do, in many forms, including the reflog, even after you delete the branch).

git rebase --onto origin/master topicA

I wrote a blog post on the different uses of git rebase --onto: http://krishicks.com/blog/2012/05/28/git-rebase-onto/

The thing is, you don't know _why_ something happened any more with a merge strategy than a rebase strategy.

In fact, you know less.

It's as if someone was doing work against an old, old, old version of your code. Say they did a bunch of work, months out of date, and then wanted to merge it in. Almost assuredly there'd be tons of conflicts, the code wouldn't match up at all with the current state of the world, and what they did in the commits would be entirely useless knowledge without also knowing what resolutions to the conflicts happened as part of the merge commit.

So anyone that looks back at those commits that were made against the old codebase have to know that what they're looking at is horseshit which had to be patched up before it could be merged in.

If they had used a rebase strategy they'd have updated their commits to the current state of the codebase such that they could be cleanly applied. Now you still know what feature(s) were added, but in a way that actually took into account the current state of origin when the commits were rebased.

Your example is incorrect.

If you're the maintainer of wonnage/foo and bar submits a pull request from bar/foo, bar/foo should have been rebased on top of wonnage/foo, not the other way around.

(And if you are in a situation where rebasing on top of bar/foo would actually do anything, that means you have local commits that haven't been pushed to origin, in which case accepting the pull request is dangerous.)

There's a simple concept at work here: origin wins.

Whatever is on origin at the moment of you wanting to merge your code is what your code has to work against.

When you use a rebase strategy you're allowed the opportunity to make sure your commits actually work on top of what's on origin, and fix merge issues with those commits as they happened.

So you rebase, run into a conflict, fix the conflict, run your tests, make sure everything's green, and continue the rebase.

When you do the same thing with a merge strategy what happens is you end up fixing the conflicts as part of the merge, and your fixes are hidden in the merge commit.

This means your commits prior to the merge commit are broken. They didn't take into account the work that was on origin at the time, and thus they are useless without considering the conflicts that were resolved during the merge.

The history you describe is not useful unless it's green and could be applied to origin without conflict. The only way to ensure this, both before and after your commits end up on origin is to do so via a rebase strategy.

“They’re running a sweatshop with an app."

Guys riding around in air-conditioned cars all day calling their working conditions a sweatshop.

What if Uber can't actually pay them what they want? Is the solution to force Uber to not fire any drivers, to pay them more than they're able? And by what insane reasoning should they be forced to pay more? Uber isn't owned by the government, and isn't the sole dispatcher around (and certainly not in SF!).

If Uber's business model can't support paying the drivers more than there's nothing that can be done except for the drivers that don't like the conditions to quit. If that means that Uber then goes out of business, so be it. No amount of protesting is going to fix that.

You really couldn't think of a better name?

I did consider this when using those as examples, but they were the first that sprang to mind. The sites that are utterly unusable tend to be forgotten entirely.