gerhardi

I think that trained athletes actually know better of their limits and when to not push for the maximum intensity than “regular office worker” in their corresponding field. The fatigue and risks of near future subpar performance are more concrete than with office work.

Also in any field, it ofcourse requires time, work and experience to become actually good enough to give yourself some slack.

To explain a bit further, I feel that this approach also makes you more ready for promotions and working with new people/industries/tech. To me it seems that people who worked their ass off and received a promotion “as a reward for their hard work” seem more prone to burnout later on with more responsibilities. We can be better than that - don’t get promoted for hard work, get promoted for SMART work!

When you’re actually good at something you do, dont give 100% in all the time. Get a feeling of what your clients/boss/etc. need to be happy and try to exceed it marginally.

- Be capable of 100 in normal working hours

- Be expected to deliver 70

- Deliver 80

This provides also a good buffer for errors and other unexpected stuff. And reduces stress.

It’s the regulation. I work on EU GDPR tech stuff currently (this stuff is HOT at the moment and I have a feeling that even many large companies are quite late on the train!) in financial services sector and while some data needs to be kept for x years according to the law anyway, rest really needs to be deleted and at least my current client really doesn’t want to play with the financial risks involved with getting caught in a possible EU GDPR compliance audit.

What kind of patterns would be interesting to find out in this dataset? A thought came in to my mind to do some data acrobatics and possibly publish a dashboard based on this data if I can arrange some extra time.. (didnt check any possible terms of use for the data yet)

"Ironically, Deloitte Touche Tohmatsu Ltd. is the world’s No. 1 security consulting group (at least, for now)."

From what I have seen, it really seems that the shoemakers aren't usually wearing shoes themselves. My experience is that the internal systems for example in Big Consultancies are often something that the companies wouldn't be proud to design/deliver for their clients.

Yes, this is exactly our use case. Every now and then a need for new attributes or metrics appear that are to be calculated or otherwise logically determined for the "sessions" generated. Sometimes a new device model / software version starts providing new attributes with the transmitted event and we can just add metrics and aggregations based on those attributes into the session generator if those attributes are present on an event.

The capacity for large volume ("real life scale") of transactions with reasonable verification latency is something that I have always seen as the real blocker with Bitcoin. I continue to be slightly surprised that the issue isn't covered more actively.

Happy resident of a MongoDB environment here! In one of my projects, we are collecting IOT "clickstream" with slightly varying contents, around 20 million inserts per day. These are then transformed into "sessions" that are inserted in another collection. Everything works as it should.

Reporting is based on PowerBI and aggregations are scheduled through cron jobs to refresh the data sources that PowerBI uses. Realtime metrics are not needed, but could easily be implemented through the "session" generator by calling PowerBI Streaming API in parallel when writing a document.

This was also included in the query editor of Microsoft's Power BI in the release a month or two ago. First you select the columns to be used as a source then start writing example values to the new column to be generated. It also shows the generated M/PowerQuery expression.

It can't do miracles, but this is time saving in many cases like when you want to concatenate values from different columns in a new format into a single column and so on.

Well, you can basically do it once with the restaurants in your new neighborhood. Otherwise it would probably ring the alarm bells for someone if the same guys are complaining and receiving vouchers multiple times. Anyway, it's a scam.

Yes, I just see this kind of arguments coming from quite senior level engineers every now and then. I see the reasoning that application/system level logic should be kept separate from the database, but aggregations are a good example in my opinion of things that database engines are good at, and also as the aggregated data does not insert any new operative data/transactions this should be mostly fine.

Especially banks really need to maintain the transaction log. One could also argue that keeping the aggregated balances could be some DB side trigger on update operations for separate "balances" table or generated with some kind of hourly/daily batch job to not put too much load on the operational DB with every customer browsing the online bank.

Triggers get a lot of hate because of separation from application level version control etc., but these are also long discussions to get into.

edit: This article's contents are good to be included with all the most junior level application design/development training material.

I love the location timeline feature. For example last summer I did a road trip driving from Finland to Venice, Italy through Sweden, Denmark, Germany, Austria, Switzerland and France. Many times after the trip I've checked up exact locations for DSLR photos and actual hiking routes on the mountains. What was the name of the small medieval German town and the cafe that we had the perfect flammkuchen by the town square? Just a sec, I'll check out on the location history! This is only one kind of a example where I have found the location timeline useful.

Edit: Also I've found it useful to check actual driving times for commuting and other trips. "Last tuesday I left home at 08:35 and took the tram and it took me 17 minutes."

Yes correct. In a way it's a combination of philosophy, agreed practices and techical solutions. I think this one is a good introduction: The What, Why, and How of Master Data Management https://msdn.microsoft.com/en-us/library/bb190163.aspx

What you are saying is correct. In this case I would have the join of t3 on the same indent level as the join of t2 as t3 table has also the common key with t1. Somehow I just find the parent comment style not so intuitive for me.

I always keep the joins indented from the table that they are joined to:

  select    t1.col1,
            t2.col2,
            t3.col3,
            t4.col4
  from      table1 t1
                join table2 t2 on t2.colx = t1.colx
                join table3 t3 on t3.coly = t1.coly
                    join table4 t4 on t4.colz = t3.colz
                join tablen tn on tn.coln = t1.coln
  where     tn.colnx in (...)

            -- Table 3 and Table 2 have some values while Table n value is not something OR Table n has value that is exactly something
            and (
                    (t3.col = x and t2.col = y and tn.col != z)
                    or 
                    tn.col = z
                )
  ...

So in above you can see by the indent on which table some other table is joined to. Tables t2, t3 and tn are related to t1, but t4 is related to t3, not directly t1.

Hundred times this. You see Qlik/Cognos Analytics/PowerBI/Alteryx/whatever sales guys making demos that make executives drool over the seeming easiness and wow-factor these tools are capable of producing. When the time comes to plug those over your production operative systems, CRM, whatelse, there comes "the now wait a minute" moment especially if your systems and their data models happen to be even slightly on the more complex side.

Edit: The basis of succesful implementation of these tools is to have the data in digestible format and I feel that transforming the data to that business usable format is where the big job is.

In my opinion well done ETL and DW are not going anywhere, even though in some circles they are said to be things of yesterday. Then there's a huge difference between an OK ETL/DW and a Brilliant ETL/DW. Designing a good ETL process is as large parts business and context knowledge as it is a application of data engineering skills. For example, it requires business knowledge AND data engineering knowledge to determine what kind of granular level advanced metrics could or should be calculated during ETL. Service level metrics and service level categorization for different kind of customers/claims/orders/... would be a perfect simple to understand example problem - there could be attributes and value ranges behind multiple relations that probably need to be taken into account and understood.

Edit 2: I've been involved in both sales and execution of so called data discovery sprints, which are a 4-6 week periods where we bring a data engineer, a subject matter expert and client key personnel working together and let them go "fishing". The key thing is that this provides an low cost way for the clients to possibly gain insight on the potential their data could provide. On the other hand, many prospective clients just have so messy data that this data discovery job can't be recommended, which leads to other possible opportunities (MDM, ETL, DW).

As a amateur photographer, I have always been attracted to the Fuji X-series products. Currently I'm packing Nikon FX system but before my current camera body I had X100s which I carried with me on many trips and really loved the results and the joy of photographing with it. The fixed focal length was non-issue 95% of the time. Now having returned to the Nikon system, I can totally get results that are what I'm expecting but it doesn't feel the same! Maybe one more generation and I'll sell my FX gear and move to the Fuji camp.

With X-series Fuji provides the proven UX to handling the exposure settings, compact sizing and excellent image quality. Secretly I'm still hoping for a compact Nikon mirrorless FX body with Df / Fuji X / traditional exposure settings. Let's see!

Average chinese meal for one over $35? Sounds like a lot..

The recording URL might well point to an VPN / private network address (at least it should).

Earth is a sunlit object in this picture, the luminosity is the same level as during the day on earth - would you see stars in your photos if you took a correctly exposed photo of something during daylight on earth? I don't think this would happen :) The dynamic range difference between day light objects on earth and the stars on the sky is huge.

... "The highest pyramid in the whole universe that is located in Central America!" :)

Hmm how about: You have a 1 liter bottle of 99% alcohol. How much of the alcohol you should evaporate to have 98% alcohol left?

If one uploaded a video shot with drone to youtube/etc. and google / facebook / ... showed advert on the same page as the drone video is shown on, wouldn't Google / Facebook be monetising with the video and the drone flight would have become illegal?

Now coin flip wouldn't be anything near 50% accurate, unless there is a world where more than a small fraction of startups survive!

Off topic: I recall talking about this last year and I believe we have met quite randomly over some beers when I was travelling in Istanbul in July 2013! Good luck for your business!

I have a quite strong feeling that certain complex automated systems within financial services / insurances domain could reach those LOC levels. Including all the frontend side, internal backend logic, possible web services, internal tools, tests, tens to hundreds of interfaces to different kinds of external services, report generation, libraries, etc.

There are valid scenarios for robbing during the night - for example in many holiday destinations with villas, holiday apartments etc. it is expected that when there are people inside the house, there is also cash money, laptops, tablets, smart phones and other small easily carriable items with value worth the effort available.