hrbrtglm

With paymill looking like a stripe clone, it may be a good solution to split the revenues stream.

Now, if only they could fix bugs hanging around for more than 6 years, it would be cool too. ie: https://bugzilla.mozilla.org/show_bug.cgi?id=488725

Also a comodo certificate.

http://imgur.com/s4yQqLk

I followed the link you provided and it seems the previous android version had different taskbar icons, which I found a bit easier to understand.

Still, Android and iOS do not help much with discoverability in my opinion, and the newest the version, the worst it is. What's next, heptagon for sending email and decagon for contacts ? I feel so old :(

May I ask a few questions : - what the "Back" triangle is for when there is a back arrow on the top left of the app, doest it perform the same action ? - As the "circle" is home, I guess there is no way to hide this taskbar as you could not go back to home screen, right ?

I can grasp the meaning of some icons, a cross for closing, an arrow to go back or forward, but the ones sitting on the lower taskbar ??? What the hell could be the meaning of a triangle, a circle and a square ?

Has someone already used this one ?

If I were told, we were going to change our measure system, I would be kind of scared, could it be better or worse ! After all, the hardest part is not the real use but the idea of the switch.

Now, if you could just use the international ISO 216 paper size, I wouldn't have to mess with my PDF export settings and just push some A4.

The CRM webapp I'm working on with the basic features I think such a system should have :

  - Customers, suppliers and leads management.
  - Calendar
  - Tasks (billable time tracking)
  - Opportunities, Quotes, invoices, credit notes and purchases
  - Expenses (rebillable)
  - Products and services with inventory and moving average costs
  - reporting
  - customer dedicated page

Each tenant is assigned a subdomain (No vhost, all routed by the app to the same codebase) with the name he choosed when he subscribed. So this name is retrieved by inspecting the host header the browser send while connecting to the webapp, this name is checked in the public schema to find an appropriate uuid assigned (if it exists of course).

Something like :

  App_DB (database)
  -- public (public schema)
     -- tenants (tenants table)
        -- tenant_uuid uuid
        -- tenant_name text (same as subdomain name)
        -- coderev numeric (for split testing)
        -- some tenant general info like creation date, choosen plan, ...
     -- some other tables accessible by all tenants like shared stats, queues, etc ...

  -- "b6e42fd1-d5b9-4de4-ba6b-6eca1dae06ff" (tenant_uuid schema name)
     -- users (it's a multi-user webapp per tenants, so ...)
        -- email (for auth)
        -- password (bcrypt for auth)
        -- etc ...
     -- other tables needed for the webapp

When the user login, his credentials are checked in his tenant schema, the tenant name and uuid are set in his session for not messing with other tenants data.

I think there are 2 ways to deal with connection pooling (If we are both talking about PgBouncer || pgpool connection pooling to be sure).

- The first one is to create a new PostgreSQL user for each tenant in order to access only his schema. Then there is no need to set the schema search path prior the connection object as by definition his search_path will be set to $user,public (http://www.postgresql.org/docs/9.1/static/ddl-schemas.html) But then, I can't really see the point of a connection pooling. I don't really like this solution, so many users, roles, passwords ... - The second (which I choose) is to connect with a role having access to all the schemas. You can set this one for connection pooling. The search_path is only set to public, and the queries use the qualified name to access the tenant data, ie: SELECT * FROM "b6e42fd1-d5b9-4de4-ba6b-6eca1dae06ff".users You can use the connections readily made available by the connection pool and query the data for the tenant you need without touching the search_path. The security is now dealt with the application and not the DB.

For the multi-version domain model, the coderev set in the public.tenants schema is retrieved with the tenant_uuid associated with the tenant name and then used by the webapp controller to route to the associated code version. No need for a second server, just a different branch on the same server. Transitioning a user then just really mean updating his schema and routing it through the new codebase. And that's why I said it's very ugly, because I still need to implement a good DDL and DML stategy in order to navigate between different versions without losing data.

Like you said, it's a tough environment. Unfortunately, I have nothing elegant to propose but I'm also interested in reading how others deal with that kind of stuff. I still lack fluency to write a blog post or something like that which could encourage debating or discussions. I'd be very glad if yourself find some interesting stuff on this topic to share it with me, my email address is my hn username @ gmail.com

With MySQL, you can choose 2 way to architecture your data : - the fully isolated way : each tenant has his own database. - the shared way : all tenants share the same schema, you usually use a tenant_id column on tables to query your data adequately.

Some other RDBMS like PostgreSQL offer you a third way between the fully isolated a shared data system : - all tenant access the same database but their data are stored on their own schema. It's up to you to decide if the tenants access their schema with the same database role (kind of user) or if you create a role for accessing solely their own schema.

Example :

App_DB

  -- Public schema

     -- tenant_id uuid

     -- tenant_name (subdomain name for example)

     -- etc ...

  -- tenant (named after the public.tenant_id)

     -- your application tables

  -- tenant (named after the public.tenant_id)

     -- your application tables

  -- tenant (named after the public.tenant_id)

     -- Some beta tables model for version n+1 of your app or whatever, you can add more table columns for this very tenant if he needs special features for example.

You can give each tenant his own schema, that way you can even make some nice split-testing when you incorporate new features in your app requiring changes in you database. Once a fraction of your tenants have tested/approved (much better if they choose themself to take part of a beta) the new model, you are good for rolling out progressively a full implementation to all of your tenants.

I don't miss these websites at all.

I think building a website targeting desktop and mobile devices is a limiting factor in terms of creativity.

These software corps better be persuasive because a whole economic part of USA will be endangered then !

If the American gov wanted to kill the cloud, then good job ! I want to clarify that I do not trust my own gov neither ...