It went closed source a few years ago, but Quasar Accounting is still free to use (for non-POS installations), and the last GPL version still works fine as well.
518 karma · joined August 6, 2010
More details in http://xn.pinkhamster.net/download/New_Process_and_Tools.pdf
Ripple Singapore's currencies are an actual digital version of Hayek's proposal for competing currencies, defined as and redeemable for a specific weight of metal.
I documented my experience at http://xn.pinkhamster.net/blog/misc/buying_an_audi_under_inv...
I'd love to get a Lovejoy Bakers sourdough baguette or a New Seasons french baguette delivered every morning, maybe with fresh squeezed orange juice.
The REST API allows you to retrieve metadata for a relational data model and to perform CRUD operations. The data model itself is typically created through Salesforce's web interface, although there is a Metadata API that can be used to manage the schema by uploading XML files.
There are standard objects (think database tables) for things like Users, Accounts, Contacts, Task, Events, Leads, and Opportunities (note Salesforce's history as a CRM application) which you can extend with custom fields, and you can create custom objects, and define the relationships between objects.
You can also expose custom server-side functionality as a REST endpoint by writing code in Apex, a java-like language, that runs on Salesforce's platform. This can be useful for dealing with multiple records in a single transaction, for example. The Apex code can also be managed through the Metadata API, the Tooling API, or the web interface. (Salesforce pretty much never deprecates old APIs so you can still use the version of the SOAP API you were using five years ago, for example. But this can also be confusing to new developers who find there's a lot of overlap between the old SOAP API and the newer REST API, and a little bit of overlap between the old Metadata API and the new Tooling API.)
One of the unique features of the Salesforce platform is a robust security model. Each object has row- and field-level security that can be configured through the web interface. This is particularly useful for apps used by large organizations. Different types of uses can have access to different fields. Ownership of records can role to the management within an individual's national division, for example. Your app doesn't have to enforce security. You call the API as the user, using an OAuth token, and see the data to which the user has access.
Another unique feature of the platform is that it is licensed per user. You don't scale by adding VMs or containers. It's nice to not have to think about scaling hardware, but most developers would probably rather think about scaling problems than ponder all of the convoluted licensing options Salesforce offers, much less talk to a sales rep. As a developer of an app for distribution to multiple customers, you also have to be cognizant of the various types of orgs (a company's Salesforce instance) in which your app might be installed.
If you're building a standalone app that doesn't need to be installed alongside customers' Salesforce CRM apps, and just want to take advantage of Salesforce's data modeling, security model, and API, you can use database.com, which has more developer-friendly pricing (in terms of transparency, not necessarily impact on your wallet).
Prime has become a bit less useful over the past year due to the introduction of Add-On Items.
Call the doctor and get the procedure code. Then ask for the amount that is going to be billed and the tax id of the person or company that will be sending the bill to the insurance company.
You may need to get multiple procedure codes and talk to multiple billing departments. For example, I recently wanted to find out how much an MRI would cost. There's a fee to perform the MRI and a separate fee for reading the images. These are performed by different people, and therefore billed by different people.
Next, call or livechat your insurance company. Ask them to run a test claim. Give them procedure code(s), the amount billed, and the tax id of party sending the bill. The insurance company can then tell you what the allowed amount is, that is, how much the insurance company and the medical provider have agreed upon for the specific procedure. If you have a deductible that you haven't yet met (and the procedure isn't something covered or partially covered before the deductible, such as preventative care), the allowed amount is the amount you will be billed by the medical provider.
Obviously, this is a cumbersome process. Running the test claim took about 10 minutes in my case. This is apparently not a process that the insurance company has optimized for. But by going through the process, you are sending a signal that price transparency is important.
With MRIs, it turns out that at least one local company has recognized the value of price transparency: https://twitter.com/xn/status/311886680145666048 (They also happen to be about $400 cheaper than the amount my insurance company negotiated with a large hospital.)
Affiliate link: https://app.liquidplanner.com/signup_a/161/516fb8abc586ae567...
I've started developing a kanban-style project management tool (http://www.octoberswimmer.com/about/) based on huboard, but I still recommend LiquidPlanner to everyone.
The screen-sharing also doesn't work very well, at least on linux. You either have to share your entire desktop, across all screens, or a single window of an application.
If I publish a review of a work of art, including a reproduction of the work, in a magazine, my copyright would cover the entire article including the reproduction. I wouldn't be claiming copyright on the original work.