Thread: New Zealand Postgis DBA job vacancy

Mat be of interest to someone here... http://careers.eroad.co.nz/vacancies/showVacancy/11 Brent Wood

Gavin
 
BTW: Americans dont walk anywhere ..we drive our 2 gallons to the mile Hummers everywhere we go
(so Im hoping that gas is cheap there)

I dont know anything about New Zealand but can one live on South Island and work on North Island
and or vice-versa?
 

---

Date: Wed, 26 Dec 2012 20:17:23 +1300
From: GavinFlower@archidevsys.co.nz
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] New Zealand Postgis DBA job vacancy

On 25/12/12 09:46, pcreso@pcreso.com wrote:

Mat be of interest to someone here... http://careers.eroad.co.nz/vacancies/showVacancy/11 Brent Wood

I know some people in Auckland who do PostgreSQL, I've emailed them about it.

Curiously, EROAD's head office is about an hours walk from where I live!


Cheers,
Gavin

On 12/26/2012 10:30 AM, Gavin Flower wrote:
> Please do not top post!
>
>
> In New Zealand we generally use petrol, or diesel, measured in litres -
> though there are some cars powered by natural gas.  I think the USA is
> one of the few places not using the metric system.

Actually we do, we just pretend we don't:)

>
>
> Cheers,
> Gavin


--
Adrian Klaver
adrian.klaver@gmail.com

pcreso@pcreso.com wrote:
> Mat be of interest to someone here...
>
> http://careers.eroad.co.nz/vacancies/showVacancy/11
>
> Brent Wood
>


I attended a technical conference in the US recently, and someone
posted an Auckland job flyer (not this same organization,
though). He included a statement regarding New Zealand expatriate
work visas and something about government bias against more
experienced workers. He did not phrase it like that literally, of
course, but rather emphasized that it was notably easier for
foreigners under age 30 to get permission to work. Can anyone
with direct experience comment on this government-sanctioned
discrimination?

pcreso@pcreso.com wrote:

Mat be of interest to someone here...

http://careers.eroad.co.nz/vacancies/showVacancy/11

Brent Wood

I attended a technical conference in the US recently, and someone posted an Auckland job flyer (not this same organization, though). He included a statement regarding New Zealand expatriate work visas and something about government bias against more experienced workers. He did not phrase it like that literally, of course, but rather emphasized that it was notably easier for foreigners under age 30 to get permission to work. Can anyone with direct experience comment on this government-sanctioned discrimination?

On 12/26/2012 10:30 AM, Gavin Flower wrote:

Please do not top post!


In New Zealand we generally use petrol, or diesel, measured in litres -
though there are some cars powered by natural gas.  I think the USA is
one of the few places not using the metric system.

Actually we do, we just pretend we don't:)

Cheers,
Gavin

On 12/26/2012 11:20 AM, Gavin Flower wrote:
> On 27/12/12 07:39, Adrian Klaver wrote:
>> On 12/26/2012 10:30 AM, Gavin Flower wrote:
>>> Please do not top post!
>>>
>>>
>>> In New Zealand we generally use petrol, or diesel, measured in litres -
>>> though there are some cars powered by natural gas.  I think the USA is
>>> one of the few places not using the metric system.
>>
>> Actually we do, we just pretend we don't:)
>>
>>>
>>>
>>> Cheers,
>>> Gavin
>>
>>
> Actually, I learnt the metric system mostly from an American textbook on
> Physics at high school in year 12 (then called 6th form for us).

In a round about way, I came to use Postgres to help deal with our split
personality regarding the metric system. I was working at a greenhouse
at the time and new rules came down from the Federal government dealing
with the tagging of plant material for retail sale. One of the rules was
that the tags must list the volume of the container the plant was sold
in and that the volume should be in both imperial and metric units. This
was just the tip of the iceberg, so I put together a database solution
to track all the necessary information. After some false starts I
settled on Postgres as the back end.

>
> In New Zealand, we spend a lot more time putting down Australians than
> Americans - but if anyone was to try and invade Australia, then the half
> of New Zealanders not already living in Australia would rush to defend it.

Sort of the way we look at Canadians, especially since half of BC seems
to be in town at the moment.

>
>
> Cheers,
> Gavin


--
Adrian Klaver
adrian.klaver@gmail.com

Gavin Flower wrote:
> On 27/12/12 07:54, Berend Tober wrote:
>> ...regarding New
>> Zealand expatriate work visas and ... that it
>> was notably easier for foreigners under age 30 to get
>> permission to work. Can anyone with direct experience comment
>> on this government-sanctioned discrimination?
>>
> I think it might be that they want healthy workers who likely
> will pay lots of tax before requiring to much medical treatment -
> most people use the public health care system in New Zealand, so
> it as assumed you will not be relying on private medical insurance.

That would be an obvious-enough inference to draw.

I guess I was hoping for more practical, direct insight, such as
"Despite how skilled and a productive worker you might be, don't
bother applying if you are anywhere near middle-age, or if you
are likely to become middle-aged." There was this interesting
1976 movie called "Logan's Run" about a dystopian future that
similarly devalued the experienced.

The current job posting by Brent Wood does not specifically
mention age requirements/restrictions, and does not specify any
particular amount of experience, but they do in fact require
"experience". Knowing that the visa quota system is biased
against age, one might reasonably conclude that no one with more
than 5 to 10 years experience would be able to qualify because of
the government restrictions.

It might have been polite of the advertising organization to make
that clear, as did the guy that posted the flyer at the technical
conference.

I wonder, if an applicant were within the government-approved age
range, but then worked long enough so as to exceed the limits,
would their work visa suddenly be withdrawn, having contributed
to the tax base and maybe established a family there, then be
forced to vacate the premise simply because they aged out?

On 12/26/2012 11:20 AM, Gavin Flower wrote:

On 27/12/12 07:39, Adrian Klaver wrote:

On 12/26/2012 10:30 AM, Gavin Flower wrote:

Please do not top post!


In New Zealand we generally use petrol, or diesel, measured in litres -
though there are some cars powered by natural gas.  I think the USA is
one of the few places not using the metric system.

Actually we do, we just pretend we don't:)

Cheers,
Gavin

Actually, I learnt the metric system mostly from an American textbook on
Physics at high school in year 12 (then called 6th form for us).

In a round about way, I came to use Postgres to help deal with our split personality regarding the metric system. I was working at a greenhouse at the time and new rules came down from the Federal government dealing with the tagging of plant material for retail sale. One of the rules was that the tags must list the volume of the container the plant was sold in and that the volume should be in both imperial and metric units. This was just the tip of the iceberg, so I put together a database solution to track all the necessary information. After some false starts I settled on Postgres as the back end.

In New Zealand, we spend a lot more time putting down Australians than
Americans - but if anyone was to try and invade Australia, then the half
of New Zealanders not already living in Australia would rush to defend it.

Sort of the way we look at Canadians, especially since half of BC seems to be in town at the moment.

On 12/26/2012 11:45 AM, Gavin Flower wrote:

>
> I have a close friend who is working on embedded software for a green
> house controller.  He would love to use PostgreSQL, but they started
> using SQLite and pg does not appear to be suitable for embedded systems.

We used a controller system that came from across the border in White
Rock, BC. As a thought problem I contemplated what it would take to
replicate it in Open Source software. Came to the same conclusion. I
could see Postgres on a computer somewhere tying together multiple
controllers/sites. For the controllers themselves Sqlite or something
even more light weight would be in order. Hardware constraints are less
of an issue than before. It is more an issue of setup/integration and
the realization that Postgres would really be overkill for the task at hand.

>
>
> Cheers,
> Gavin


--
Adrian Klaver
adrian.klaver@gmail.com

On Wed, Dec 26, 2012 at 02:45:18PM -0500, Berend Tober wrote:
> I guess I was hoping for more practical, direct insight, such as
> "Despite how skilled and a productive worker you might be, don't
> bother applying if you are anywhere near middle-age, or if you are
> likely to become middle-aged." There was this interesting 1976 movie
> called "Logan's Run" about a dystopian future that similarly
> devalued the experienced.

If it's like the Australian system then there several different
categories you can come in on.  A way it look at it is that you can
come if you can demonstrate that you will not require welfare support,
either by bringing enough money with you or having skill in some area
where there is demand.  But then there's an exception for people under
30 who are unlikely to have been able to build anything up yet, you
assume that if they have any kind of degree then they will pay for
themselves in the long run.

> I wonder, if an applicant were within the government-approved age
> range, but then worked long enough so as to exceed the limits, would
> their work visa suddenly be withdrawn, having contributed to the tax
> base and maybe established a family there, then be forced to vacate
> the premise simply because they aged out?

In my experience, as long as you're working there's never a problem
(assuming your visa allows you to work).  Marrying an Australian has to
be one of the more common ways to get permanent residency, since that
is one of the easier ways.

I've never heard of anything like the weird cases you get with those
American green cards.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
   -- Arthur Schopenhauer

Hi Gavin,

[apologies if msg reference chain mangled -- forgot to Cc list  <:-( ]

On 12/26/2012 12:45 PM, Gavin Flower wrote:

> I have a close friend who is working on embedded software for a green
> house controller. He would love to use PostgreSQL, but they started
> using SQLite and pg does not appear to be suitable for embedded systems.

I'll second that!  Though, to be fair, there is a wide range of
applications that "embedded" can address.  The resources that are
available to one may be (several!) orders of magnitude different
than others.

I am currently using pgsql in an embedded system though suspect
I may have to port everything over to another engine for deployment.
There are too many assumptions made about the underlying hardware
available for pgsql that are at odds with the goals of most
embedded systems.  (e.g., I need to be able to have the DB reside
in "immutable" memory -- and the "writable" memory requirements
carefully constrained)  So, "cleverer" solutions end up prevailing.

A pity as a single embedded system deployment probably puts more
"seats" in play (e.g., easily 10,000 - 1,000,000 per design) than
*years* of "natural growth" would, otherwise.

--don

Hi Martin,

[apologies if msg reference chain mangled -- forgot to Cc list  <:-( ]

On 12/26/2012 2:04 PM, Martin Gainty wrote:

> most of us in the US choose to be *delightfully ignorant* of
> anything that doesnt fit into our 30 seconds (or less) lifestyle

"30 seconds"?  Seems an *eternity* for most of the folks I meet!
(i.e., if you haven't answered your cell phone by the *second*
ring, the followup text message -- "Where are you?" -- is *delivered*
in that time frame!)

Sheesh!  How can people live like this??  Can you spell "short leash"?

> metric system requires rudimentary math skills instead of
> entertainment so we collectively choose not to think of such things

Thinking (entirely) *in* metric doesn't.  The problem is working
with *both*, simultaneously, requires some mental agility.

Nearby, we have one of the few (only?) stretches of roadway that
is marked in metric units (actually, I haven't driven it in a while
and vaguely recall something about RE-marking it in "conventional"
units).  To most folks, it is a disturbing experience as they aren't
accustomed to thinking in these.  ("No, that's not 100MPH but
100kmph... big difference!")

OTOH, working entirely within the "english" system is significantly
taxing if you want to deal with more than one unit of measure at
a time.  Feet/miles/yards/inches.  Gills/gallons/pints.  etc.

I'm tickled that I've got a 1/3C measuring cup and a 1/4T (not 't')
measuring spoon (I bake a lot).  Otherwise, it's a real chore
hitting some of these "odd" measurements!

[The idea of *weighing* ingredients is anathema to me -- and I
can't imagine it would be as expedient as using "fixed volumes"!]

> I spent 3 months outside the US this year and was *forced* to use
> my brain to convert petrol containers from liters to US gallons
> It was nice to be able to come back to the US to put your brain
> *in park* and let the big brains in the statehouses and Washington
> tell us -what to do and -provide us the funding to do their bidding
> at least until 1 Jan 2013!

> so...why doesn't Postgres port to embedded systems?

IME, it requires lots of resources (the vast majority of embedded
systems are resource starved -- resources == $$ and when you are
selling things in volume, every penny saved adds up quickly!).
Lots of MIPS, lots of RAM -- even the code footprint is "significant".

OTOH, (again, IME) designing with the "relational table" construct
makes coding a very different experience!  Already being biased
in favor of table-driven algorithms, I took this opportunity to
move all the "const" tables out of my executables and into the
DBMS (which takes a performance hit but keeps the code much more
mutable).  I've gone so far as to hide the filesystem from the
applications -- objects that would have typically resided in
ad hoc files are now stored in structured tables (eliminates
the need to write lots of special parsers to be able to impose
structure on what would otherwise be unstructured "bytes")

[This last issue owes nothing to pgsql, though, as any RDBMS
can provide that structure/capability]

<shrug>  We'll see... it's been a learning experience (make
one to throw away)

--don

Hi Martin,

On 12/27/2012 8:31 AM, Martin Gainty wrote:

>>> so...why doesn't Postgres port to embedded systems?
>>
>> IME, it requires lots of resources (the vast majority of embedded
>> systems are resource starved -- resources == $$ and when you are
>> selling things in volume, every penny saved adds up quickly!).
>> Lots of MIPS, lots of RAM -- even the code footprint is "significant".
>>
>> OTOH, (again, IME) designing with the "relational table" construct
>> makes coding a very different experience!  Already being biased
>> in favor of table-driven algorithms, I took this opportunity to
>> move all the "const" tables out of my executables and into the
>> DBMS (which takes a performance hit but keeps the code much more
>> mutable).  I've gone so far as to hide the filesystem from the
>> applications -- objects that would have typically resided in
>> ad hoc files are now stored in structured tables (eliminates
>> the need to write lots of special parsers to be able to impose
>> structure on what would otherwise be unstructured "bytes")

> so do you reduce CPU or IO when you take a java variable final int
> foo=1; and insert foo as a const column in a table?

[For the most part, I don't use Java as most of my projects have
real-time constraints and the lack of determinism in Java blows
that out of the water]

My (original) comment above is meant to address taking tables
of constants out of code and moving them into the DBMS -- *fetching*
them at run-time and using them in their normal role AS IF they
had been hard-coded into the executable.

E.g., given a Julian day, most folks would convert it to a (month,day)
tuple using a table like:

days[] = {
   31,   /* Jan */
   28,   /* Feb */
   31,   /* Mar */
   30,   /* Apr */
...
   31    /* Dec */
}

Instead of putting this table in the code as a const datum, I would
store it in the DBMS and retrieve it as/when needed for the conversion.

[This is a silly example but one that is easy to understand]

Among other things, it allows me to change the contents of the
table without having to release a new executable

[Again, this example is silly in this regard as January will *always*
have 31 days so there will never be a need to change that!  OTOH, if
the table is used to determine how far to advance the timing of the
spark in an internal combustion engine with respect to engine RPM's,
then you *may* want to change/tweek that table at some time in the
future to obtain better performance or accommodate changes in the
manufacture of the engine -- without changing all the code that
*references* that table.  If that table is embedded in the actual
executable, this isn't very easy.]

As far as my parsing comment is concerned...

The structure that a table can impart to the data that it represents
allows you to identify that data *once*, stuff it into the appropriate
fields and then never have to parse the raw data object again.

E.g., early email readers maintained the user's "mailbox" as a simple
ASCII text file.  New messages were appended to the end of the file.
When it came time to enumerate the messages or find a particular
message, the program had to parse the ASCII text sequentially knowing
the form that a message took so that it could identify the start
(and end) of each individual message.

If you were handed that ASCII file and asked "How many messages does
this contain", you would have to parse the file sequentially, knowing
the format of mail messages (in detail!) and count them.

If, instead, you have a table called "mail" with fields called
"From", "To", "Date", "Body", etc. then it's easy to determine
how many messages you have (count) or locate the most recent message
from "Bob", etc.  The application can concentrate on the service(s)
that it wants to provide instead of having to be encumbered with
the trivialities of parsing message formats.

[Parsers are rife with opportunity for coding errors -- especially
those coded ad hoc!]

--don