Offices in Palo Alto, CA, Kansas City, MO, Boston, MA. We’re a mostly distributed team and also have engineers in Minneapolis, MN, Canada, Indiana, and South America.
We make the Beam Smart Presence System - the world’s best telepresence device. Innovative companies and distributed teams all around the world use Beam to communicate effectively and travel instantly. If you’re interested in robotics, unique human-computer interaction challenges, telecommunications, hardware, wireless networking, and/or scalable infrastructure, let’s talk!
Some of the positions we’re hiring for are on our careers page - C++ developers, Python developers, electrical engineers, developers with solid networking and wireless expertise - but we’re also looking for talented and experienced frontend (JS, UI/UX) developers and operations and security engineers.
Learn more and apply at https://suitabletech.com/careers/. If you have any questions, or are specifically interested in a JS/frontend or Python/backend role, email me at hans@ <our company domain name>.
Hi Stuart! I'm an engineer at Suitable Technologies (makers of the Beam). Sorry to see the Beam didn't make it into the video, but it was really inspiring to see this talk. Thanks!
Hi! I've been using the Beam all over the world, it's amazing and I just wish I had one of my own. :-) (Probably need a ground crew and private plane as well!)
The beam was actually in the talk, but would you believe about five minutes before the talk there was a local problem with the Wi-Fi. Totally not on Suitable Technologies by the way.
To properly support people videoing in, conferences will need to provided dedicated WiFi on a separate channel. Current conference WiFi is reliable enough for checking email during a boring talk, but not for remote attendees.
It's hard to get conference venues to care. It might require an interpretation of the Americans with Disabilities Act (in the US) to insist that reliable WiFi to support remote video attendees is as important as reliable elevators.
I agree with what you're saying in general. In this specific case, the venue WiFi was not the issue. It was human error on the day, but not something we need to rake over here.
However, is a really interesting point about the reliable Wi-Fi in public spaces. If telepresence is going to be used as a viable way for quadriplegics like me to visit these public spaces, then we're going to need decent and dedicated Wi-Fi. Which in 2014 is both fairly easy to do, and not that expensive. But you're right, I do fear that it may need some Interpretation of legislation to make this work. In the UK we have to Disability Discrimination Act [0] which I think of is the same things as the ADA in the US.
Totally agree on the need of dedicated connections... for many reasons ;)
however often a problem with conferences and large gatherings is that even if there are separate Wifis and on different channels the (constructive/destructive) interference is still bad enough that the connection slows down anyways.
I know there are solutions out there, it's a matter of cost and time before they become widely available. (I'm hoping it will happen tomorrow ;))
"Generally speaking, legal practice is fairly inefficient and anti-technological. My cofounders and I are not the first to notice; there is a veritable graveyard of failed legal technology companies."
The issue, in my opinion, is that law firms have a direct incentive to be inefficient and bill more hours. Why would a firm invest in time-saving technology when it will literally mean sending smaller bills to clients? The firm would have to raise their rates or work even harder to drum up business in order to maintain revenue.
This is a really unfortunate situation, but it's reality. I hope Amicus Labs has a strategy to address this.
To be fair, the author is a fresh law school graduate. What does he know about whether legal practice is inefficient or not?
I was a summer associate at a large New York law firm, and the level of technology was fairly typical for corporate America. We had a centralized document management system that integrated version control and generation of deltas. We had a centralized, searchable repository of every document generated for every client, which we could use to avoid duplicating effort when doing new work. We did everything via Blackberry e-mail and Outlook calendaring.
Beyond the generic "you can always have better document management" I'm not sure what else there was to do. The major legal research databases (Westlaw and Nexis) have god-awful interfaces, but there isn't much law firms can do about that, since there is a huge barrier to entry in that market (the proprietary databases).
The fundamental problem is that nearly everything you do for a client is a one-off. It's 90% similar to what you've done for a previous client, but that remaining 10% is not very amenable to technological automation. Can you write some software that will cross-reference an SEC disclosure against the client's big pile of haphazardly-assembled internal documentation, which are handed over in God-knows how many formats? If so, then you're going to make some serious money. If not, then well that's how that graveyard of failed legal technology companies builds up.
The big recent advance in legal technology has been software to speed up document review, which leverages document search technology that has really improved (and obsoleted a large number of discovery attorneys in the process). Law firms have been quick to embrace such software, as well as services such as "in-sourced" discovery centers in places like West Virginia. To date, legal technology hasn't advanced much beyond that, largely because computer technology for working with documents hasn't evolved much beyond search.
In a previous job I worked for a firm that provided services to law firms and I can say that your assumption is missing some important information.
Law firms actually do spend quite a bit on technology to improve their practices. Many cases these days include so much documentation provided during the discovery phase that it's very difficult to process.
Some of the technologies that I personally oversaw implemented at law firms include, 1) document scanning and indexing, 2) electronic document conversion, 3) native file metadata extraction and indexing, 4) document culling (filtering large document sets based on metadata and extracted keywords), 5) document review (to find document relevant to the case), 7) electronic searching of legal records (like Lexis-Nexis), 7) fax servers (true, law firms use a LOT of fax)
While I agree that there are areas in which law firm technology can be improved, there is a fairly healthy market for software solutions to improve productivity at law firms (though much is aimed more at secretaries and paralegals than attorneys).
Law firms also have a direct incentive to win. Working more efficiently doesn't necessarily mean you have to work fewer hours. It just means you can get more done in the hours you do work.
Just signed up to give it a try, and after entering my email address and password I was presented with a button that took me straight to GMail. Of course I could have simply switched tabs, but this was an awesome little detail that made me smile.
I've always seen advertising as a game of iterated prisoner's dilemma. If every business cooperated and agreed to not advertise, consumers would still be able to seek and find products and services they wanted, and businesses wouldn't need to spend money on ads. As soon as one business started to buy ads, however, they'd have an immense advantage and competitors would quickly follow suit. So as soon as one business stops cooperating and starts advertising, the entire market devolves into the equilibrium we see today: our lives are completely saturated with ads.
The fact that business can carry on as usual when everyone is forced to cooperate in Sao Paulo shows that advertising is mostly a huge inefficiency.
This wasn't really impressive to me until I started playing around with the dual pole filter. Awesome! Something like this should have been directly embedded in my prof's DSP lecture notes.
In my first job out of college, I worked for a company that built industrial test equipment (machines that snapped airplane wings in half, shook cars around like they were driving down a bumpy road, that sort of thing).
The tool we used to write the supervisor code and GUIs for machine operators was a language called Alltalk. It was inspired by Smalltalk and developed by an old graybeard at the company. Reading the description of Squeak/Smalltalk brought back some fun memories. A few interesting highlights:
- Alltalk ran in its own VM. You could create objects, change their state, and save the entire stack/image back to the original VM. Running the VM again would pick up execution right where it left off. This let someone do crazy things like email an Alltalk image to another engineer and say, "Here's the machine state halfway through an emergency shutdown. The actuators all came to rest in 10ms, but it's taking way too long to shut down the hydraulic pumps. Any ideas?" and the engineer could run the VM and debug away.
- The Alltalk VM had its own object inspector and terminal/interpreter. So you could walk up to an Alltalk instance connected to a live machine with motors spinning at 20krpm, for example, open up the inspector, and code away. Realize you need a low-pass filter on the motor speed feedback sensor? Create the object, tweak the parameters, and wire it into the signal chain live.
Yeah, I totally understand. I'm actively looking for ways to increase the level of trustworthiness and to make people feel confident that I won't take the money and run.
Good call. There's a screenshot of the notification they receive on the next page, but I just put in a disclaimer about never spamming them or posting on their walls.
Cool. Another thing I noticed is that I didn't go through and actually pick anybody for step 2, and it didn't stop me until I put in a dollar value for step 3. Maybe it should validate right after step 2?
Offices in Palo Alto, CA, Kansas City, MO, Boston, MA. We’re a mostly distributed team and also have engineers in Minneapolis, MN, Canada, Indiana, and South America.
We make the Beam Smart Presence System - the world’s best telepresence device. Innovative companies and distributed teams all around the world use Beam to communicate effectively and travel instantly. If you’re interested in robotics, unique human-computer interaction challenges, telecommunications, hardware, wireless networking, and/or scalable infrastructure, let’s talk!
Some of the positions we’re hiring for are on our careers page - C++ developers, Python developers, electrical engineers, developers with solid networking and wireless expertise - but we’re also looking for talented and experienced frontend (JS, UI/UX) developers and operations and security engineers.
Learn more and apply at https://suitabletech.com/careers/. If you have any questions, or are specifically interested in a JS/frontend or Python/backend role, email me at hans@ <our company domain name>.