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.
As someone with a fair amount of experience on an electric board (ZBoard type), I like that Boosted puts the battery packs and electronics at either end of the board. Other boards have the battery pack in the middle and it gets in the way of clearing obstacles.
Also, hand controller works nicely for me so I see no obvious advantage to having my weight distribution impact the board's motion.
An interesting way to solve the issue is to hide the bar when scrolling down, and show it when scrolling up.
This pattern is one of the many irritating things about the mobile Chrome and iOS 7 browsers that prevents me from using devices implementing either.
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'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.
Ianal, but in a deposition he would be asked whether they were his tweets or not.
If he denied they were, he would be asked further questions and possibly caught in a lie. Such as "is this the only time that your account has been used by someone other than yourself?" or "So you are saying that this is the only tweet that you didn't make but the others before and after you did". And so on. My guess is that he would be advised to tell the truth to prevent getting further trapped as far as his credibility. There may also be other people that he discussed the tweets with that could be brought into the picture as well under oath in court I'm guessing. Bottom line: Denial is easier said than done.
To add on, some attorneys spend their whole lives tearing apart people who lie. Unless you are professional psychopath, you are completely outclassed here.
Agree. Would also add that if you lie infrequently you are probably not prepared to know all the potential pitfalls of lying and how the other person can tear you a new one if you want to call it that.
Additionally I've noticed a loose correlation between people who lie and who their parents are or how they were raised. Nothing scientific of course, but people whose parents don't hold their feet to the flame are generally more likely to think that they can get away with something because "the other guy is stupid". People whose parents are either very intelligent or hold them on everything they say are generally more practiced at thinking of the various possibilities that can come about to refute something they would say.
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.
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.
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?
You are describing a construction checklist. Things to be done, like run unit tests before deploying, implement feature 12345, or weld a brace plate over the bolted supports.
Construction checklists are objective and empirical.
Whereas a submittal checklist contains communication tasks. For example, "Obtain signoff on requirements changes." In a narrow sense, there's a measurable outcome: Did the customer sign? But the real purpose of such an activity is to avoid a major misunderstanding. It's about communication and synchronizing knowledge, not measuring the progress of the project towards "done-ness."
To that extent, a stand-up serves the same purpose. Not that you have a checklist saying "hold standup on Monday, December 2nd," but rather that they are different paths to the same objective.
If your checklist exists to codify things you know at the time you compose the checklist, it's a construction checklist. Unit tests are another way to accomplish the same thing.
But if the purpose of your checklist is to make sure that Alice talks to Bob about the idea that Carol wants to pitch to Dave, that's a submittal checklist.
If that still isn't making sense to you, read the book before dismissing the idea just because I'm not explaining it persuasively.
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.
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.