beermann

I love the idea of recommending how to approach this topic with a GP. We've been a little careful, as described in another comment, about crossing the line of providing medical advice. Currently, we see Pacifica as a self-help tool. We have to find the right ways to do some of this because we don't want to upset the FDA. The truth is that they have the same goals that we do, and we will try to work with them to provide the best application we can, while making sure it is safe to use.

Regarding "privately," we had a slightly different take. Because of the stigma, there are so many people that aren't seeking help. We think that providing an application that can help you understand where some of your thoughts come from might help you realize that you can start talking about this. And ultimately, our hope is that creating a consumer application that is widely used might contribute to breaking down some of those walls. It's a lofty goal, but our mission is to do what we can to combat the stigmas around mental health.

This is a great question. Technically, we don't store Protected Health Information ("Personal health information (PHI), also referred to as protected health information, generally refers to demographic information, medical history, test and laboratory results, insurance information and other data that is collected by a health care professional to identify an individual and determine appropriate care."). Everything is self-reported in Pacifica.

That said, we treat our data as if it were PHI. We have a Business Associates Agreement signed with AWS, and take all of the precautions they require for an app that would claim it is HIPAA compliant. Technically, we could claim that we are HIPAA compliant, as we don't store PHI. But we didn't want to say that just for the sake of saying that.

The bigger question, in my mind, is about whether or not a situation would arise as you mention. The FDA recently provided a little more clarity on some of this (http://mobihealthnews.com/39775/fda-clarifies-the-line-betwe...). Specifically, Pacifica seems to fall outside regulation as it "Claims to promote relaxation or manage stress when there is no reference to anxiety disorders or other reference to a disease or condition." We try to be pretty careful about the language that we use. We don't mention things like Generalized Anxiety Disorder, Panic Disorder, OCD, etc.

The truth is that it still seems like a grey area. That same article mentions that we should not claim that we treat anxiety if we want to stay unregulated. I think that we're on the fence here. In the future, we will go after FDA clearance in any case. We just need the means to do so.

Thanks for the questions. Hopefully I can answer the satisfactorily:

1) We don't do anything with it other than use it to provide the best user experience we can. We won't turn it over to other organizations. Technically, the thought records could be used to identify an individual based on your voice, but someone would need to gain access to them. They are stored and transmitted encrypted.

2) Currently we retain all data. This may change in the future. For the progress to work correctly you'd want to retain a month's worth of data. The idea is that thought records help you analyze your thinking over time. This may take months, or longer. I kind of like the idea of allowing the user to set their own retention policy though. It would take a little work to implement, but I think it's reasonable.

3) Yes, if you close your account we will destroy everything (except for what we need to retain for purchasing records, but that is anonymized when we delete an account). You can't currently request that through the app though, you have to email us at info@thinkpacifica.com.

4) We actually have implemented a lot of offline functionality. We just couldn't get it to where we wanted to before launching. As a bootstrapped company, we need to try to ensure our longevity in order to provide this. But yes, it's definitely on the roadmap.

Happy to answer anything else!

As a fairly young company, this is something we can clearly improve. The privacy policy we have was written by our lawyers and is fairly standard. Could you expand a bit on what seems murky?

In addition, it obviously isn't enough to just say that "we take privacy very seriously," although we do. While we don't store Protected Health Information, we treat the data we do store as such and are taking the same steps to protect users' data that we would have to if we were.

Thanks for the comment. We actually agree entirely. One of the most effective ways to combat anxiety is through a combination of psychiatric drugs administered alongside CBT. Unfortunately, not everyone has the means to pursue professional help, for a variety of reasons. Of the 40 million people in the U.S. with anxiety disorders, only 1/3 of them are actually seeking help. We're hoping that Pacifica can help bridge that gap, ideally helping people find the care that they really need.

Chartist.js just had a lot of support on HN, although I haven't used it. I've used Raphaël but customizing it can actually be a bit hard. Chart.js is simple, easy to use, and just powerful enough for most cases.

I like Highcharts a lot and we are paying for and using it, but be careful with the licensing. Chances are you'll need to pay $390 for it unless you're using it on a single domain, in which case it's $90. And that's for a single developer. 5 developers and multiple domains = $1500 without support, and there's nothing in between. And if you don't get the license and support you don't get hotfixes and updates, which seems odd.

There are a lot of other charting libraries out there. Look at the licensing before you commit to any of them.

This might be an unpopular opinion, but I've seen the exact opposite of this. Given too much freedom, I've seen designers and product managers derail entire development cycles. Compare a few days for a single designer against two weeks for even a small development team and not only have you lost an amazing amount of money, but the opportunity cost of not getting something into the users' hands and iterating on it is huge.

For the same reason I've also pushed for aesthetic changes to be moved to following iterations. If your wireframe is solid and agreed upon up front, then iteration can happen on both the development and the design side as you move forward. I think it's alright to release something that isn't fully baked because what you learn in the end is so much more valuable than trying to get it right the first time.

Bottom line: get something out the door and iterate. Too often people don't do either. Either they try to perfect it and take too long to learn from it, or they push it out and move on to the next thing. Nothing is going to be perfect the first time, so just get it out there and continue to work on it. Just because you're targeting a feature in a single iteration doesn't mean you should forget about it afterwards.

Definitely agree. I use liquibase so that I can check database migrations into source control and have an easy way for other developers to update to the new schema without having to understand a whole lot. It also provides a nice way to drop your whole database and recreate it if you need to.

In addition, much like how unit tests force you to think about how to write code, rollbacks help when writing schema migrations to make sure that something could be undone if necessary. In practice, I've rarely used them though, and if you do it's likely going to be on a dev/staging server.

I used mybatis at a former company. I liked it, but on the spectrum of ORM-like frameworks, it had just enough non-code configuration behind it that junior developers, or developers who aren't working in that type of code very often, struggle with how to get new data objects persisted. In my opinion, this stemmed from using XML files to define the mappers and queries. Most people just never knew where to look for that stuff, or exactly how it should be used.

In the end, I try to pick the option that is easiest to read and understand. I've had a terrible time with JPA/Hibernate (I hate that the ORM ends up affecting your schema at all), I had a good experience with Mybatis, and so far I'm really liking JDBI (although see my other comment here about documentation). I don't want raw JDBC, but JDBI seems to be the right tradeoff of power/ease of understanding. I think that the annotated use of mybatis would get you this as well, but I haven't used it.

I've been using JDBI for a new project for about a month or so and I like it a lot as well. I will say that the documentation is a bit sparse though, or at the least hard to find by digging through blog posts. When I figure out how to do what I'm trying to do however, I love it.

For example, it took me a while to find out that @CreateSqlObject was a thing and that it solved any hackery I was trying to do to have my DAOs reference one another. Or if you google "jdbi transactions," you aren't led to a page that actually shows you how to use @Transaction. I feel like the only thing holding back widespread use is some better documentation.

I've been using Ionic for about a month now. For the most part, it's a great tool to get something off the ground. I'm not positive if it'll hold up to our expectations of a native app yet, but I'm optimistic. I have had a few issues as well though. Most of it has to do with understanding the intended app structure. The documentation is getting better though.

For example, getting ion-side-menu to work was difficult for some reason. Looking at the documentation now, it shows that the directive is a child of ion-side-menus and a sibling of ion-side-menu-content. I'm not sure if that was always there, but I didn't notice it until now. The framework has been going through some change as well, so some of the examples out there are already outdated.

Regardless, I think Max and the guys at Drifty are doing great. And it's exciting to see a Madison getting mentioned in the development community. Nice work guys.

Edit: Ionic, not Angular

This is a step in the right direction for them, but in order for Dropbox to be the go-to provider for small businesses they're going to need to integrate better into the every day lives of people at those companies. Features like volume shadow copy and image based backup, local backup, centralized management, and reporting are common features provided by competitors targeting the small business market.

Dropbox was designed for consumers and I think the core experience lends itself well to them. They certainly have that market nailed down. But there's a reason there is a huge market they've left untouched and I don't think it's going to be easy for them to enter it without some fundamental changes to how their product operates.

Disclaimer: I work for a small online backup provider.

StudyBlue is hiring in San Francisco, CA and Madison, WI. We're a small startup with a big reach. Come help us improve education for millions of students worldwide.

We're currently looking for a client-side application architect.

Send me an email at dale (at) studyblue (dot) com if you'd like to hear more.

StudyBlue - San Francicso. Currently hiring a Senior Front-end Developer. Great office location in SOMA.

http://www.studyblue.com/about/about/jobs/senior-application...

We're looking to fill the position as soon as possible. Feel free to email me at dale (at) studyblue (dot) com.

San Francisco, CA: Senior Product Designer

You are a talented, hard working human being who is hungry to do big things. You’re a doer. You’ve got the imagination to design heretofore unseen study experiences, and the experience to see that they get shipped. You’re organized, and it shows.

You maximize utility and minimize effort for users. You’d rather call users “people”. You believe, as we do, that the product experience is the core of the brand.

You’re comfortable working quickly and collaboratively, iterating towards a solution. Your taste exceeds your ability, but only just. You reconcile attention to detail with a broad product vision to deliver delightful, seamless, multi-device experiences for students worldwide. Your work speaks for itself, and when called upon, you can articulately speak for your work.

The idea of a million students relying on a product you dreamt up then designed energizes you. You’re up for changing education, for everybody, forever.

The job:

As Senior Product Designer, you’ll move product from sketching (wireframes and workflows) to shipping (hi-res comps and production-ready assets). You’ll work closely with product managers, developers, writers and researchers.

Must have:

- Work: please include samples, or links.

- 4+ years designing mobile- and web-apps for consumers.

- Strong communication and presentation skills.

- Fluency in Illustrator, Photoshop, & the like.

- Teamwork comes standard.

Nice to have:

- Product copywriting experience.

- HTML and CSS experience.

- Experience with exploratory research and usability testing.

- Bonus skills: video production/editing, animation, illustration.

Email jobs at studyblue dot com

http://www.studyblue.com/about

I was writing something to do this a while back actually. Just recently AirBnB wrote about it as well: http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-t.... They're using Backbone on both the client and server to accomplish what you're talking about. I haven't seen a complete framework that does this yet though.

I have this argument with people a lot. I'm surprised that nobody talks about serving multiple applications from the same service layer. Sure, you can have a web app and then a separate API for mobile clients, but why not just have a RESTful interface that can be used by all of them?

This doesn't necessarily mean that you can't still do server-side views if you wanted to. But by separating the view rendering from the service layer you provide a bit more flexibility. Designed correctly, the argument becomes moot. Either you're creating a controller, models, and event callbacks on the server, or you're creating them on the client. Client-side javascript frameworks are getting so much better that it really just comes down to finding the best tools for your team.

Madison, WI - StudyBlue

We're a quickly-growing startup trying to fill several positions as we hit some big milestones this year. Excellent candidates will be excellently compensated.

Available positions: Senior Application Developer, Community Manager, iPhone Developer, Android Developer, Interactive Designer

For more information: http://company.studyblue.com/about/jobs/

Please elaborate. So many people on HN love their newest language of choice and overlook frameworks like this because it isn't as sexy. As I mentioned in my previous comment, we have a pretty large site by most standards and are happy with GWT.

Regarding the debugging features, I think things have gotten a lot better. Debugging is done in Eclipse and you're debugging java, not javascript (if that wasn't clear to some). It honestly works really well. I think there are also quite a few benefits other than type-safety. Easy implementation of asynchronous calls that serialize Java objects is one example.

GWT does have its drawbacks, but we do a lot of complex work in it with very minimal native javascript and support a site with hundreds of thousands of active users.

What's the general consensus in the HN community regarding GWT? We're pretty happy with it and I think it has a lot of advantages over other frameworks.

StudyBlue (Madison, WI) is hiring for the following positions:

Marketing Manager

Front End Web Developer

Senior Applications Developer

iPhone Developer

Android Developer

Network Operations Director

QA Engineer

We're a funded startup out in the midwest (they do exist) building educational tools for high school and college students.

For more info: http://company.studyblue.com/about/jobs/

I see a ton of small startups having problems on the legal side of things and they can't pay a couple grand to handle simple things like incorporation, creating terms and conditions, etc.. I wish there were more respectable groups that did this to alleviate the burden on young companies.

ha, I was one of the presenters there, for Sharendipity. You're right that Aardvark didn't talk much about the tech, considering it was for Developer Fridays. They did focus a lot on expanding the ways you could use the social graph in FB though. I thought it was nice to see that they've been acquired, although I thought the price tag was a bit surprising.

The desktop client just integrates really well with my workflow. When I have to move from one app to the browser and open up a new tab it takes me out of my current mode of operation. It's a subtle nuance in liking the desktop client better than the browser but I think it's important. You also contend with other distractions in the browser. All hell breaks loose when I see my bookmarks to HN, Reddit, Facebook, etc. and there goes my productivity...

For our company, with just a couple of founders, chat rooms wouldn't make sense because we want everyone to know everything. We'd just have one master chat room. In Yammer, hashtags provide a similar feature to chat rooms, although all conversations are aggregated into one stream. I guess we could have separate chat rooms for checkins, bugs, etc. but now I'm flipping between tabs when I could have just tagged by comment with the right hashtag.

Interesting product. I think it could work well for large companies where the chat rooms make more sense but I'm not sure it would work as well for a startup. Adding features like hashtags and search would help too.

I also really like that Yammer provides a desktop client. I mention that a lot of the barriers to communication have to do with integrating into my everyday routine. When I have to go to a web page, it breaks up my workflow and I end up just not using the product like I should.

We're using Flex Builder which should allow us to create all of the GUI controls we need. It's $250. Regardless, it's true that the free tools aren't all that useful.

Flex is pretty cool. It allows you to publish applications to the web or to the desktop via AIR without many changes at all. If Java is approved, then I can't see why AIR applications wouldn't be. The security model is a bit more strict than Java.