If it won't be simple, it simply won't be. [source code] by Miki Tebeka, CEO, 353Solutions

Monday, January 09, 2017

353Solutions - 2016 in Review

Happy new year!

Let's see how 353solutions did in 2016. We'll start with the numbers and then some insights and future goals.

  • Total of 193 work days (days where customer were billed)
    • Up 23 days from 2015
    • Out of 261 work days in 2016
  • Out of these 61 days are in workshops and the rest consulting
  • 18 workshops
    • Up from 14 in 2015
    • Go workshops
    • First docker workshop (teaching with ops specialist)
    • First open enrollment class
    • In Israel, UK, and Poland
      • Only 4 out of the country (vs 8 last year, which is good - I prefer to fly less)
    • Workshops range from 1 to 4 days
  • Revenue up 10% from 2016
  • Several new clients including GE, AOL, Outbrain, EMC and more
  • Social network keeps providing almost all the work
    • Doing good work will get you more work
  • Workshops pay way more than consulting
    • However can't work from home in workshops
    • Consulting keeps you updated with latest tech
  • Python and data science are big and in high demand
    • However Go is getting traction
  • Having someone else take care of the "overhead" (billing, contracts ...) is great help.
Last Year's Goals
We've set some goals in 2015, let's see how we did:
  • Keep positioning in Python and Scientific Python area
    • Done
  • Drive more Go projects and workshops
    • Done
  • Works less days, have same revenue at end of year
    • Failed here. Worked more and revenue went up
  • Start some "public classes" where we rent a class and people show up
    • Did only one this year
  • Publish my book
    • Failed here, though I'm close. Probably Q1 this year.
Goals for 2016
  • Work less while keeping same revenue
  • Work more from home
  • Publish my book
  • Publish a video course
  • More open enrollment classes

Monday, December 26, 2016

Automatically Running BigQuery Flows

At a current project we're using Google's BigQuery to crunch some petabyte scale data. We have several SQL scripts that we need to run in specific order. The below script detects the table dependencies and run the SQL scripts in order. As a bonus you can run it with --view and it'll show you the dependency graph.

Friday, November 25, 2016

Using built-in slice for indexing

At one place I consult I saw something like the following code:
This is good and valid Python code, however we can use the slice built-in slice to do the same job.

Also when you're writing your own __getitem__ consider that key might be a slice object.

Friday, September 16, 2016

Simple Object Pools

Sometimes we need object pools to limit the number of resource consumed. The most common example is database connnections.

In Go we sometime use a buffered channel as a simple object pool.

In Python, we can dome something similar with a Queue. Python's context manager makes the resource handing automatic so clients don't need to remember to return the object.

Here's the output of both programs:

$ go run pool.go
worker 7 got resource 0
worker 0 got resource 2
worker 3 got resource 1
worker 8 got resource 2
worker 1 got resource 0
worker 9 got resource 1
worker 5 got resource 1
worker 4 got resource 0
worker 2 got resource 2
worker 6 got resource 1

$ python
worker 5 got resource 1
worker 8 got resource 2
worker 1 got resource 3
worker 4 got resource 1
worker 0 got resource 2
worker 7 got resource 3
worker 6 got resource 1
worker 3 got resource 2
worker 9 got resource 3
worker 2 got resource 1

Tuesday, August 30, 2016

"Manual" Breakpoints in Go

When debugging, sometimes you need to set conditional breakpoints. This option is available both in gdb and delve. However sometimes when the condition is complicated, it's hard or even impossible to set it. A way around is to temporary write the condition in Go and set breakpoint "manually".

I Python we do it with pdb.set_trace(), in Go we'll need to work a little harder. The main idea is that breakpoints are special signal called SIGTRAP.

Here's the code to do this:
You'll need tell the go tool not to optimize and keep variable information:

$ go build -gcflags "-N -l" manual-bp

Then run a gdb session

$ gdb manual-bp 
(gdb) run 

 When you hit the breakpoint, you'll be in assembly code. Exit two functions to get to your code

(gdb) fin
(gdb) fin

Then you'll be in your code and can run gdb commands

(gdb) p i
$1 = 3

This scheme also works with delve

$ dlv debug manual-bp.go 
(dlv) c 

Sadly delve don't have "fin" command so you'll need to hit "n" (next) until you reach your code. 

That's it, happy debugging.

Oh - and in the very old days we did about the same trick in C code. There we manually inserted asm("int $3)" to the code. You can do with with cgo but sending a signal seems easier.

Blog Archive