blog.rhp.org

It looks like the DrvFS driver requests execute permissions on all requests to remote drives. With recent versions of samba, this can result in unexpected Permission Denied messages when trying to open any file without the executable bit set.

As a work-around you can update your smb.conf and turn off execute permission checking:

acl allow execute always = yes

Install Postgresql using the bigsql distro

Follow the instructions at the install page.

Install tds_fdw1-pg96

C:\bigsql>pgc install tds_fdw1-pg96

Setup a database and user in SQL Server and a test table

CREATE TABLE test1 (id integer, name varchar(255));
INSERT INTO test1(id, name) VALUES (1, 'hello, world'), (2, 'I am a banana');

Set up the extension in postgres

CREATE EXTENSION tds_fdw;
CREATE SERVER 
    tds_test_server 
    FOREIGN DATA WRAPPER tds_fdw 
    OPTIONS 
        (
         servername 'localhost', database 'test', 
         port '1433', msg_handler 'notice', character_set 'UTF-8',  tds_version '7.1'
        );

CREATE USER MAPPING FOR 
    testdev 
SERVER 
    tds_test_server OPTIONS (username 'username', password 'password');

Note that if you do not specify character_set, you will get an unable to connect error and you will bang your head against the wall for hours

Create the foreign table

CREATE FOREIGN TABLE test1 (id integer, name varchar(255)) SERVER tds_test_server OPTIONS (table 'dbo.test1');

Query your new table

SELECT * FROM test1;

Enjoy!

Junior / Associate Developer:
1. Bang your head against the wall long enough to know what questions to ask
2. Take direction
3. Try things harder than you think you can take on, fail sometimes.
4. Know when you’ve failed
5. Move from team to team with considerable friction
6. Demo new features and bug fixes
7. Produce simple solutions to simple or complicated problems

Developer:
1. Make decisions unsupervised
2. Understand code organization
3. Hunt down defects
4. Improve code quality
5. Break down stories into concrete and estimable tasks
6. Understand end user perspective for the product
7. Move from team to team with downtime
8. Present in-depth case studies on feature work within the team
9. Understand when complexity is necessary

Senior Developer:
1. Understand sections of the code in-depth
2. Refactor Aggressively
3. Make large scale design decisions
4. Break epics into valuable and testable stories
5. Understand long term vision
6. General understanding of business requirements driving product
7. Work with other teams to discover cross-product code reuse
8. Move from team to team with some downtime
9. Mentor Junior Developers
10. Prepare and present trainings to other teams
11. Understand when to simplify

Principal/Lead Developer:
1. Set long term vision
2. Understand entire code-base
3. Work with other teams to inform architecture
4. Mentor Senior Developers
5. General understanding of other code-bases in the organization
6. Understand business requirements driving product in depth and general understanding for other products
7. Move from team to team with little to no downtime
8. Prepare and present trainings to cross-team groups (guilds, interns, etc)
9. Understand and document areas of Technical Debt and propose solutions
10. Understand complexity budget for a single product and allocate accordingly

Senior Principal/Lead Developer:
1. Act at a Principal level across multiple products
2. Take part in deciding company-wide architectural vision
3. Move from team to team seamlessly
4. Prepare and present company-wide trainings
5. Understand business requirements for a given product vertical
6. Suggest the complexity budget for multiple products

• PowerPoint is dumb
• Slides are the worst way to engage an audience
  • But they are low effort
• People often think in bullet points and slides are conducive towards that
• Slide decks are pre-organized notes that can be given out after the fact
  • So you don’t have to pay attention
• Building a slide deck signals, “I AM PREPARED THIS IS IMPORTANT I AM IMPORTANT”
• Working on a slide deck is a dodge to get out of doing real work
• Slides present the illusion of consensus

Martin Fowler has written an article about Microservice design, which hits home with me:

MonolithFirst

This pattern has led many of my colleagues to argue that you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile. .

I am becoming more and more convinced that proper software architecture is reactionary, and being disciplined enough to find ways to refactor large projects in situ, rather than trying to scrap and rewrite (as every engineer I know is wont to do).

I keep a daily work log adapted from a template I got years ago at a job.

It’s useful for me, to be able to look back at what I was working on as well as a convenient place to keep notes. It can be useful to keep yourself honest, as well as a place to track interruptions if you’re into that.

What I Worked on Today
———————-
What I Will Work on Tomorrow
—————————-
Things that are on the Horizon
——————————
DB Stuff
——–

Code Stuff
———-
Special Notes
————-
SQL
—

template

Quickie shell script to use sublime as your editor in cygwin

Create ~/bin/subl

#!/bin/bash
/cygdrive/c/Program\ Files/Sublime\ Text\ 3/subl.exe cygpath -wa "$*"


You may want to add the -w flag if you want to use it as your commit message editor for git/svn/hg/etc, which will cause it to wait until you save and close the file in Sublime Text before returning control.

I’m a unixy guy working on a .NET codebase, and while I can’t get away from Visual Studio completely, I do like to be able to run msbuild from a cygwin shell. Converting the MS supplied VCVARS.BAT file to something bash could understand was a bit of a PITA and I don’t want to have to do it again, so for your enjoyment is my version of vcvars.sh: vcvars.

Don’t blame me if it doesn’t work, but it might get you started.

1. Facilitate rather than dictate architecture
2. Negotiate for the reduction of technical debt
3. Lead by example
4. Embrace emergent design
5. Refactor relentlessly, harvesting application idiomatic patterns
6. Design with the expectation of change
7. Extract Embedded Frameworks
8. Make design choices at the last responsible moment
9. Do not try to predict the future
10. Rely on tightly coupled team discussions to make and socialize design decisions
11. Choose simple solutions that can be replaced later once more complicated design is required and when the limitations are more well known
12. Do not enable those would use architectural considerations as a pretext to force waterfall processes
13. Rely on team members to make rational, adult decisions regarding code, and use refactoring as a mentoring opportunity
14. Do the minimum amount of upfront design necessary to clear easily visible pitfalls, but expect to have to pivot at any moment.

xUnit Test Patterns: Refactoring Test Code