keredson

if you're already accustomed to python+flask and want to try react, try https://github.com/keredson/bottle-react. (Bottle is a lighter-weight version of Flask.)

Also check out: https://venturebeat.com/2017/08/28/8th-wall-raises-2-4-milli...

Supports Unity, and works on both iOS and Android out of the box. (I'm not affiliated, just a supporter.)

it can! :) >>> wordninja.split('salesexchange') ['sales', 'exchange']

not likely. corporate payouts happen all the time based on share ownership.

you're right about the detail of his point (people won't buy 100x just because a 100x increase in efficiency), but the point he was trying to make is correct. given a fixed global investment, a 100x increase in efficiency won't reduce costs. it will just increase the difficulty level to compensate.

I've had this thought too, but the counter argument is gold. Spending millions in fuel to dig up chunks of gold, just to go "re-bury" them in a bank vault somewhere is an equally appalling, use of the world's energy resources, but that hasn't stopped it from being a profitable venture for thousands of years.

andrew's point is that's a gotcha coming from most languages. nothing python specific.

Why would you define the type of something in the PARENT object?

that example you give does not follow a similar model. it defines the columns once (not repeated w/ every observation):

                    "columns": [
                        "time",
                        "value"
                    ],

and then the observations as a list of lists:

                    "values": [
                        [
                            "2015-01-29T21:55:43.702900257Z",
                            2
                        ],
                        [
                            "2015-01-29T21:55:43.702900257Z",
                            0.55
                        ],

exactly as i suggested in the "even if they were wedded to JSON for some reason" section of my original explanation.

Because it's horribly inefficient. It's using 49 bytes to encode 8 bytes worth of data. If your data set is a few hundred observations this likely doesn't matter. But most users of timeseries data have millions or billions. (I come from a computational finance background.)

Even if they were wedded to JSON for some reason, they could have just used a list of observations, like:

[1458000000,63.422235],

That would have cut their data costs in half.

Or just use one of the many existing formats for transmitting time series data. It's not a new topic. https://github.com/mobileink/data.frame/wiki/What-is-a-Data-...

hah. well hopefully you support http gzip compression. :)

but in all seriousness, why the timestamp at all? your examples are all spaced at 3600ms. asking for it implies certain behavior. can you handle heterogeneous interval data? missing data?

{ "timestamp": 1458000000, "value": 63.422235 },

dear lord, why? this reminds me of the old "xml binary format" joke:

<byte> <bit>0</bit> <bit>0</bit> <bit>1</bit> <bit>0</bit> <bit>0</bit> <bit>1</bit> <bit>0</bit> <bit>0</bit> </byte>

some math on how much UBI would cost in america: https://docs.google.com/spreadsheets/d/1zat6b6_8vYYBo4rVSwqN...

try editing the "UBI Benefit" and "UBI Tax Rate" to see the total budget effects.

* assumes no money from medicare, medicaid or SS, just existing welfare benefits.

> I predict that in the US, where culture of entrepreneurship, (relatively) less government intervention, and individualism rules, that UBI is completely dead on arrival no matter its merits/demerits, whatever the facts.

i agree with your premise, but not your conclusion. UBI is (much) less gov intervention that our current welfare state. and UBI allows more entrepreneurs to take risks on their great ideas. and moving social welfare from a three party system (individual, employer, gov) to a two party system (individual, gov) is in support of individualism. so the US should love UBI!

TL;DR... see git

as a CTO you're not just an employee of a company, but also one of its leaders. you have control over what you do. if you don't like the day to day process, change it.

hah. then you'll love this: this project was conceptually a port of a django tool i wrote ages ago: https://github.com/keredson/deseb

rather than call "./manage.py syncdb", call "./manage.py evolvedb" and changes to your models will be synced to your schema non-destructively. (ie: without dropping and re-building the table)

we do auto-deploy, but they aren't required to be run during the deploy process, so we just run them sometime after the deploy. but honestly i can count on one hand the number of these we do a year - i haven't put much effort into streamlining the process. whereas schema changes are quite regular. just had one tonight in fact. output from the deploy log a few mins ago:

  Executing in 3...2...1...

  BEGIN TRANSACTION

  -- column changes for table products
  ALTER TABLE "products" ADD COLUMN "dont_email_on_purchase" boolean

  -- column changes for table searches
  ALTER TABLE "searches" ADD COLUMN "tag_only" boolean DEFAULT 'f'

  COMMIT

  --==[ COMPLETED ]==--

from the one line code change that triggered it:

  1  db/schema.rb
   @@ -543,6 +543,7 @@
  
      create_table "searches", :force => true do |t|
        t.text     "query"
   +    t.boolean  "tag_only",         :default => false
        t.datetime "searched_at"
        t.integer  "user_id"
        t.integer  "page_id"

(well, there were two commits obviously)

Just to clarify, to me "data migration" is just a fancy name for a one-off script that you run during (or after) a deployment. We don't actually use the rails migration for it. (Mostly because it would overwrite our schema.rb IIRC.) But in general, yep.

I understand the skepticism. I presented it at the Houston Ruby group last year, shortly after developing it. You should have seen the looks at the start. But try it on your own project. (It takes like 30 seconds to switch.)

True, this doesn't do data migrations, and we still write the occasional(1) data migration when needed. But those are no more difficult to write, and the much more common non-data migrations are an order of magnitude easier. So net win.

(1) If your data migrations are not "occasional" (and I mean very occasional) that's a sign you're doing a poor job at modeling your data. Splitting one column into two is almost always an example of someone really f-ing up the original schema.

Think of it this way: how do you switch branches? Do you look up the most recent ancestor, check it out, migrate down to it, then back up the new branch? It's so hard I don't know any rails devs who actually do it. But with a my tool it's a one-line command. PRs w/ schema changes actually get tested now, not just eyeballed.

Also, did you even read the "rant"? Do you seriously like the proposed version control tool modeled after rail's migrations? ;)

one thing i hate about rails is writing the database migrations. (i thought: "why not just define what the schema should be, and let a diff-like tool figure out update statements?") so that's what i wrote:

https://github.com/keredson/ruby-db-evolve

been using it in production for ~1y now.

Yes it is. One of the many reasons I've migrated away from the Java world. (There are no non-spring/non-hibernate jobs left!)

Years ago I wrote a "get me the hell out of spring" tool: https://code.google.com/p/unsprung/

I also left my PhD program shortly after passing quals. I think it's a great time to bail. There are too many great classes you'll have to pass on if you're only long enough to get a masters, and you haven't yet burned a ton of dissertation hours. (Assuming you do it right - I remember my advisor being quite miffed that I wouldn't stop signing up for a full load each semester.) Grad classes really are the best learning bang for the buck/hour I've ever experienced. Just make sure you fill out the paperwork so you do get that MS along the way...