strattonbrazil.com - New pages [en]

Roger Gracie BJJ Competion Breakdown

2020-07-18T06:01:55Z

Strattonbrazil:

== Summary ==
This is a breakdown of every Roger Gracie Brazilian jiu jitsu competition available on Youtube. Roger is one of the most renowned and successful jiu jitsu competitors in the world. He is known for using simple, fundamental moves to secure victories, and his techniques are worth closer study.

This is a work in progress. I'll add videos over time.

FEEDBACK: If you notice a mislabeled move, missing technique or any other mistake you can submit feedback through [https://forms.gle/wFo6rGKbpbrytXNS9 this form].

== Roger Gracie vs Marcus Almeida (Buchecha) - 2017 ==

{{#ev:youtube|_L-Ni7bFAHg}}
* Buchecha shoots for several inside single legs
* Roger pulls guard at ~8:00
* Roger gets cross-arm control (possible setup for hip bump sweep) and moves to the side ~8:17
* Buchecha turns into him, Roger traps Bechecha's leg ~8:19
* Buchecha turns away and inverts closing guard on Roger ~8:22
* Buchecha opens legs attempting a sweep Roger--Roger pressures down and walks around back ~8:28
* Buchecha attempts to stand up, but Roger puts in hooks and takes him to the ground ~8:30
* Roger grabs the cross lapel grips ~8:40
* Roger submits Buchecha with a cross-lapel choke from back ~8:55

Buchecha is a world-class jiu jitsu champion with an especially effective single-leg takedown. For much of the beginning Roger is using his head position to block Buchecha from getting close and lifting Bucheda's belt to keep him from getting under Roger.

== Roger Gracie vs Rodrigo Medeiros (Comprido) ==
{{#ev:youtube|gDw_pDXq4dc}}
* Comprido reaches for a single leg ~2:10
* Roger secures far arm to defend attacks on other leg
* Comprido goes for a takedown putting weight and direction against Roger ~2:51
* Roger gets hooks in and and wrist control ~2:51
* Roger transitions to full guard ~2:59
* Roger pulls Comprido's arm across his chest and reaches for around his back to grab his far lapel, sweeps at 4:16
** this is a common sweep used by Roger -- if you know the name of this sweep please message me using the form above
* Comprido rolls to his side and Roger takes his back with one hook in ~4:31
* Roger grabs inside wrist control ~4:50
* Roger gives it up and starts searching for lapels ~4:58
* Roger transitions to S-mount searching for near arm ~6:20
* Roger secures far arm ~6:30
* Roger transitions to near-side armbar, Comprido taps at 6:49

A relatively quick match, Comprido uses a single-leg, which remains a very popular and effective takedown even at the top levels of jiu jitsu. Roger transitions to full guard as he often does in competition and uses a very basic, but well-executed sweep to gain mount and work to an armbar. Note how patient and deliberate Roger is moving between positions leaving little opportunity to slip out.

Roger Gracie BJJ Footage

2020-07-15T05:06:49Z

Strattonbrazil: Created page with "<youtube>_L-Ni7bFAHg</youtube>"

<youtube>_L-Ni7bFAHg</youtube>

Building Your Resume

2020-07-06T17:18:04Z

Strattonbrazil:

== Formatting ==
Make sure the resume is cleanly formatted into sections. Most resumes should use the following organization:
* header including your name and contact information
* experience (ordered most recent to least recent)
* education
* skills

Juniper Pulse on 64-bit Linux

2017-01-17T17:57:29Z

Strattonbrazil: Created page with "Juniper hasn't done a very good job of supporting 64-bit Linux. They've only provided 32-bit binaries, which has necessitated several complex workarounds. With the release o..."

Juniper hasn't done a very good job of supporting 64-bit Linux. They've only provided 32-bit binaries, which has necessitated several complex workarounds. With the release of their Pulse client, it is now much easier, but still a little cumbersome.

== Download the Client ==

The Linux client doesn't seem to be listed on the software list (only Windows and Mac OS X), so I would recommend just googling for "Juniper Linux Pulse Client" (such as this [https://kb.pulsesecure.net/articles/Pulse_Secure_Article/KB40126 link]).

Follow the whole install process so you eventually have the client installed in /usr/local/pulse.

== Added a startup script ==

Running the application directly will raise a path exception because the lib that comes with the library isn't on the path.

#!/bin/bash
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pulse /usr/local/pulse/pulseUi

== Added required 32-bit libs ==

At this point, running the client will probably raise some missing library errors. The 32-bit libraries need to be installed. For example:

sudo apt-get install libwebkitgtk-1.0-0:i386

Will get rid of the following error:

/usr/local/pulse/pulseUi: error while loading shared libraries: libwebkitgtk-1.0.so.0: cannot open shared object file: No such file or directory

== Running the Client ==

At this point, you should be able to launch the client through the bash script above and successfully connect to the VPN.

Image Synthesis

2015-01-18T06:44:32Z

Strattonbrazil: /* Project 14 */

I took this class with [http://psgraphics.blogspot.com/ Dr. Pete Shirley] in 2006. He was a very animated professor and loved talking about light and how it behaved. At one point I remember him mid sentence running into the kitchen connected to our classroom and coming back with a glass container he held up looking at it from different angles to talk about refraction.

All of the assignments were completed via blog postings. I decided to write my renderer in java for kicks, while most people chose to use C++. Looking back I slightly regret my decision since I had no experience writing "fast" java code and my renders took noticeably longer than my classmates. Still it was one of the funnest college courses I had.

== Project 1 ==

This first project samples various frequencies on the Macbeth color checker. If it passes a basic sampling check, the image color is sampled to the frame buffer. All the samples are acculumated over each time step to get a better average color. All these images were rendered at 720x480 (they seemed like good numbers). They were rendered on a Toshiba Tecra S2.

[[File:im_synth_p1_s1.png|thumb|center|1 Sample]]

[[File:im_synth_p1_s16.png|thumb|center|16 Samples]]

[[File:im_synth_p1_s256.png|thumb|center|256 Samples]]

[[File:im_synth_p1_s1024.png|thumb|center|1024 Samples]]

== Project 2 ==

This second project is similar to the first. I sampled XYZ estimates using the tristimulus curves and converted the samples on the graphics card to RGB using the Adobe RGB table conversion standard matrix. It took my poor little laptop almost two minutes to render 1024 time steps at 720x480.

[[File:im_synth_p2_s16.png|thumb|center|16 Samples]]

[[File:im_synth_p2_s256.png|thumb|center|256 Samples]]

[[File:im_synth_p2_s1024.png|thumb|center|1024 Samples]]

== Project 3 ==

These are samples from a simulated sensor. The grid is on the xy-plane and a sphere emitting light from it's surface at random vectors hits the sensor grid and accumulates XYZ factors, which are converted to RGB on the graphics card and displayed to the screen. Below are images of this program taken at different number of photon emissions.

[[File:im_synth_p3_s1000.png|frame|center|1,000 Emissions]]

[[File:im_synth_p3_s1000000.png|frame|center|1,000,000 Emissions]]

[[File:im_synth_p3_s100000000.png|frame|center|100,000,000 Emissions]]

== Project 4 and 5 ==

In the previous project, a single sphere-shaped light emitter was placed onto the sensor grid. In the example, the light source has been moved back and a pinhole has been added between the sensor grid and all other objects in the scene. This pinhole only allows vectors of photons pass through it if it they travel inside the pinhole to reach the grid. Other photons are thrown out. This pinhole-camera scheme provides a much better detailed picture than the previous implementation as it simulates a perspective frustrum just like the eye or a real camera. A red diffuse sphere bounces light from the light source to the pinhole also.

Included in this project was an importance sampling implementation. This fired photons at the diffuse sphere and directly at the pinhole. The amount of photons fired to each object was a ratio of their solid angle and the total number of photons previously fired in all directions. Because only photons sent to the pinhole and the object were fired, the scene was rendered using much fewer photons. Although more overhead was required to calculate the importance sampling, it greatly reduced the calculation time for every photon collision (having much fewer photons in the scene).

Both of these projects were added to the previous code base at the same time. Importance sampling was required to provide an more interactive debugging of the pinhole code. Final images look better than the previous project, and took much less time to synthesize.

[[File:im_synth_p4_is.png|frame|center|313,290,000 emissions (876,964 passed through the pinhole)]]

== Project 6 and 15 ==

In Project 4 & 5, the imager was modified to handle importance sampling and a pinhole camera. The importance sampling provided much faster rendering times by sending photons only at known objects in the scene, and weighting them based on their angle. The photons were generated at the sensor grid and sent through the scene until they hit a light source (or bounced too much). This seemed to provide a good sampling of the scene, but required a major rewrite of the code.

This new version of the software adds a lens to the scene as well as motion blur. To handle motion blur, the red diffuse sphere was moved from (0, 1, 3) to (1, 2, 4) over the course of the rendering. This created an easy but interesting blur effect as if the object was exposed over many sensor units while the apperture was open.

The lense was a simple biconvex lense attached to the pinhole. Upon contact with the lense, the vector was skewed based on it's angle of incidence and the refractive index of the lense (1.4 for this lense). As the photon left this lense, it would be skewed again. Snell's law was used to calculate the angles of refraction for each photon.

[[File:im_synth_p6_is.png|frame|center|Rendered using 18,000,000,000 photons -- 200,000 per sensor grid (4 hours, 11 seconds rendering time)]]

== Project 7 and 8 ==

In Project 7, we were to use our renderer to model the Cornell box. This box was compared against a physical model to compare accuracy in the rendering software. This scene's walls and light are modeled using the geometry data and color data from the Cornell box at http://www.graphics.cornell.edu/online/box/data.html.

In addition to the light source and the walls, Project 8 added fresnel effects to the renderer. Instead of the two blocks found in the original Cornell box, two diffuse spheres have been placed in the far corners of the room. A large transparent sphere is placed in the center of the room, which shows the light refracting through it.

The scene's light seems rather blurry because it was moved down slightly to not create artifacts with the ceiling, which is one giant polygon.

[[File:im_synth_p7_cb.png|frame|center|rendered at 400x400 and tone mapped. It took 4 hours to render, which is rather sad]]

== Project 9 ==

In Project 9, we were to add the Beere-Lambert Law to our renderer. The Beere-Lambert Law models the amount of light absorbed while traveling through a medium. Because different wavelengths are absorbed based on the distance they must travel through the medium, different colors can be absorbed causing different wavelengths to be more pronounced. Certain types of glass often absorb high and low wavelengths leaving a greenish tint at certain angles. Usually this effect can be seen when the light is going through the greatest distance of the glass. To compute the absorbtion at certain frequencies, euler's number e was taken to the exponent of the distance times a large negative constant (which changes based on the scene metrics).

In the picture below, five spheres are modeled. The back left sphere is a reflective sphere, while the back right is a diffuse sphere. Theses spheres are only to provide background to the scene. The spheres in front are used for comparison. The left sphere is a diffuse/reflective sphere with a purplish hue. The middle sphere is a translucent sphere that implements the Beere-Lambert Law based on the distance of the medium. This gives the sphere the slightly greenish tint. The sphere on the right is also a translucent sphere, but does not implement the Beere-Lambert Law. This was to show the difference in hues generated by this principle.

[[File:im_synth_p9_beere.png|frame|center|This figure shows several spheres. The front-middle sphere uses the Beere-Lambert Law to absorb certain frequencies of light. The front-right sphere has the same parameters as this sphere, except it does not implement the Beere-Lambert Law. This image took 5 hours and 24 minutes to render]]

== Project 10 ==

In Project 10, we were to implement participating media. Participating media involves computing physical bounces of light in media such as fog, dust, smoke, etc. where the light bounces around inside the volume instead of just diffusing, reflecting, or refracting.

To implement this, I used the standard marching technique through an axis-aligned bounding box. A ray was sampled multiple times across its vector using small steps. When these steps were inside the bounding volume, they probabilisitcally hit some of the media.

[[File:im_synth_p10_pm.png|frame|center|Participating media is used to simulate a gaseous volume under the cube. Right now my code is very ineffecient and took six hours to get these results. Earlier images not requiring participating media required far less time to converge]]

== Project 11 ==

In Project 11, subsurface scattering is added to the renderer. This implies that light hitting the surface of the material enters and bounces around inside the medium before exiting. Many materials such as grapes, skin and marble exhibit this quality. Subsurface scattering in this implementation used ray marching, where the ray enters the medium and bounces around until exiting. Because the ray actually bounced around inside the object instead of just off the surface, the rendering was far more computationally expensive than rendering this scene without SSC.

[[File:im_synth_p11_scatter.png|frame|center|Two spheres are placed side by side with a large rectangular light source placed overhead. The sphere on the left uses subsurface scattering while the sphere on the right uses just Lambertian reflections. Light shining from above simply bounces of the top of the Lambertian sphere, leaving the bottom dark and unilluminated. The SSC sphere, however, has light shining through the medium and appearing at the bottom of the sphere as many materials would]]

== Project 12 ==

In Project 12, the Heyney-Greenstein Phase Function was implemented in the renderer. The Heyney-Greenstein Phase Function (HGPF) is an imperical formula to simulate diffuse and specular reflection for a variety of materials using only two parameters. This function uses these these two parameters stored in each object and takes the incidence angle as input. This provides a much greater flexibility for different materials than using the simpler Lambertian reflection.

Finding little data as to proper values, I rendered an image using a wide range of values. From the image generated, it appears a high g-value seems important to produce a good image. This component supposedly relates directly to the angle where most of the light is leaving. It seems natural that a g-value closer to 1 will produce better pictures where light bounces off at a 90-degree angle, while a 0 value gives very splotchy results. The w-value used in the function scales the function and seems to have less of an effect after tone mapping is appled.

[[File:im_synth_p12_hg.png|frame|center|64 spheres are rendered. All spheres share the same color component, but have differing w and g parameters in the HGPF. From left to right, the g-component ranges from zero to one. From top to bottom the w-component ranges from zero to one]]

== Project 14 ==

In Project 14, for my "cool effect" I implemented shade trees. Shade trees provide a procedural, modular workflow for determining a color at a given point based on various parameters similar to the ones needed in the Heyney-Greenstein Phase Function.

These shade trees allow simple modules to be built and combined in chains or branches. Some common shade trees provide basic shading effects like Phong shading, Lambertian shading, anisotropic shading, ramp shading, etc. Other modules allow combinations and filters to provide more complex images using these simple modules.

Below are a few different spheres using some shading modules...

[[File:im_synth_p14_phong.png|frame|center|A sphere shaded using the Heyney-Greenstein module]]

[[File:im_synth_p14_ramp.png|frame|center|A sphere shaded using a ramp module. This module allows the colors to be colored based on certain points of interest]]

[[File:im_synth_p14_textured.png|frame|center|A sphere shaded using a texture module, where the theta and phi of the sphere are mapped from [0,1]x[0,1] on the texture]]

[[File:im_synth_p14_striped.png|frame|center|Here, a layered filter module with two shaders connected to it. It also uses another texture shader as a mask to determine which of these to shaders to use]]

These shade trees scale to as many levels as the effect requires. The final image at the bottom of this post shows an image using several modules. A Heyney-Greenstein module provides a shiny metallic surface. Another is a texture module to provide the metal surface. These modules must be combined in a combo filter separately from the rust so that the rust doesn't appear shiny. This combo filter is fed into a mask filter with the rust as it's other shader. A texture module is fed into the mask filter to use as the mask.

[[File:im_synth_p14_metal.png|frame|center|The sphere with just the metal texture]]

[[File:im_synth_p14_hg.png|frame|center|The sphere using the Heyney-Greenstein module]]

[[File:im_synth_p14_rust.png|frame|center|The sphere with just the rust texture]]

[[File:im_synth_p14_mask.png|frame|center|The sphere using the mask texture]]

[[File:im_synth_p14_combo.png|frame|center|The final sphere using the entire shade tree described above. This gives the overall feel of the metal, while splotching rust on parts in a natural-looking splat]]

Computer Graphics

2015-01-18T06:40:05Z

Strattonbrazil: /* College Classes */

== College Classes ==

I took a variety of college graphics courses at the University of Utah.

[[Image Synthesis]] - making photorealistic images

Interviewing a Technical Candidate

2014-08-26T00:35:47Z

Strattonbrazil: /* Forty Minutes of Coding */

I've become involved in the interview process at my company. It's been fun to learn the general guidelines we've setup for each other, but on thing I've learned is that interviewing is hard. It frustrates me how little I seem to know about a candidate after an entire hour of time with him and although we have four employees interview each candidate, I'm not confident the sum of parts is a complete picture.

I've tried to be proactive learning more about technical interviews. Time management is especially important. Having only an hour with the candidate I've found some questions can eat up a lot of time without telling me much about the programmer's coding ability or their fit on the team.

== Anatomy of a Perfect Technical Hire ==

Neil Roseman, previously a VP at Amazon, wrote [http://firstround.com/article/the-anatomy-of-the-perfect-technical-interview-from-a-former-amazon-vp The Anatomy of a Perfect Technical Hire], what he believes to be some good rules. While I don't agree with everything the article as a whole provides some great pointers.

* Don’t forget to introduce yourself to help work out everyone’s nerves.
* “Tell me about your background” is not a useful question for a tech interview.
* Pick specifics out of a resume to determine what the candidate actually did. Remember, you want people who get stuff done. Period.
* Probe when you see a resume with a long list of skills. Separate the truth from filler.
* Don’t “try out” new questions on candidates. Know what a good answer sounds like.
* Make sure you have them write code! This is too often skipped.
* Dig into algorithms, data structures, code organization, simplicity.
* Use some questions that are vague and open-ended. See if they ask you questions to find out more.
* Ask a design question. See how people think about a bigger picture problem.
* Create core competences for your company. Make sure candidates measure up well.
* Make it tough but fun. Good developers want to know they’re talking to smart folks.

== Time Management ==

As I said, I feel like time goes by so fast in an interview. It's important to keep a good schedule so you get what you want out of the candidate and also the candidate gets what he needs out of the interview (they need to get sold on your company during the interview). For an hour long meeting I like to use the first ten minutes introducing myself and going over their resume. This is followed by about forty minutes of coding starting with an easy problem and getting harder and deeper as they progress. The last ten minutes of the interview is strictly for the candidate to ask me questions.

====== The First Ten ======

After a quick introduction I briefly mention the schedule of the next hour so the candidate knows what to expect. I start by going over parts of the candidate's resume with them. I've already highlighted specific sections I want to discuss beforehand. Roseman suggests focusing on percentages in particular.

<blockquote>They might think it sounds good to say 'I improved system availability by 50%', but if we’re hiring someone for a system engineering role, I need to know they actually did that. -Roseman</blockquote>

If they say they've designed an architecture, have them diagram it on the board. Ask them what part of the design they did and dig deep to determine whether they were actively shaping in the process or just a participant.

====== Forty Minutes of Coding ======

I always start with a relatively easy question like reversing a string. This allows the candidate to relax a bit and get into programming mode. Again, questions are prepared beforehand. I've been tempted to use questions without trying them on others, but I try to stick with questions I'm very familiar with. For every question I ask I should already know common bugs people run across, edge cases, and variety of questions to dig deeper into their code. Once they complete the problem, I try to dig deeper by adding additional features or changing the scope to see how they can adapter and generalize their code.

When programming I generally try to let the candidate program in whatever language they want including pseudocode. For both my jobs out of college I had to learn the company's principle language on the fly so in general I don't care whether they know language X or library Y. If they do decide to use some esoteric language like Haskell that I don't know as well, I expect them to be able to explain to me very carefully what the program is doing. Similarly, if they claim proficiency in a language on their resume, I expect them to use it well. I've seen people who have worked with C++ over ten years and struggle with pointers. This is a bit of a red flag that they haven't been able to understand the fundamentals of the technologies they've worked with.

Most important with any technical interview is to never let the candidate get stuck for extended periods of time. It is only time wasted when I could be learning more about them. If the candidate goes silent for more than twenty seconds I ask them what they are thinking. If a candidate gets stuck it can quickly eat through the valuable interview time. Give hints and point out bugs. It's just as important to know how they think. Sometimes when listening to the candidate I've realized they don't understand the problem and by rephrasing my question I can get them back on track. Sometimes even a particularly smart candidate might not get a particular part of the problem. Make a small note and move on.

Using OpenID

2014-08-03T17:38:51Z

Strattonbrazil: /* Conclusion */

The talks at OSCON 2013 were hit and miss--something I've heard is fairly normal for tech conferences in general--but I definitely came away with a favorite. "Reducing Identity Pain" by Tim Bray was a forty-minute session on how to unique identify your users without requiring a username and password.

{{#ev:youtube|BOGXBTO2PpA}}

== Why Username/Password Authentication Is Bad ==

The talk examines some behaviors among users that are forced to make a username/password. First, making username/password's for every site is laborious. If the user comes to your site and sees they need a create a user profile with a username and password, often times they just leave your site. Why? It's hard to create a new username and password for a site that may be a one-off use. Some sites make it even harder by defining very strict password policies guaranteeing that the user will not be able to remember their password. In fact, some users will just fill the password field with random garbage and once they're logged in use cookies. Once the cookies expire they just reset their password with more garbage. This is all very laborious for the user.

[[File:fry_username_password.jpg|center]]

Even worse is when users don't use unique passwords. They implicitly trust you with their username/password, which may be used by them elsewhere. Sure, it's their fault for not using unique passwords, but it's also your fault for taking storing in the first place. Getting username/password combos hacked is horrible PR. When you accept them you have to then spend time and resources to make sure they're securely stored. What are you really getting from them that makes them worth the trouble?

== A Painless Alternative ==

So how can we consistently identify a user without going through this identity pain? OpenID is one alternative. While the protocol for OpenID may seem relatively complex, the idea is pretty simple. First, a user gets an account with an OpenID provider. Most users already have at least a Facebook account or an email account from a large provider (Google, Yahoo, Microsoft), so that's usually taken care of. When the user comes to your site, they can choose from a list of providers (actually just a list of urls designated by the OpenID providers) or manually input a url (see step 1 in the diagram below).

[[File:openid_workflow.jpg|center]]

I was initially confused where these widgets came from as they're not provided by the OpenID specification. Usually they come from individual libraries that implement OpenID.

[[File:Openid_providers.png|center]]

Once the user sends their provider url back to your server, which then forwards them to that provider (see step 3 in the OpenID workflow diagram above). This HTTP request can include specific attributes the server wants to know about the user, but in general email is always included reponse. The OpenID provider usually provides a nice list of information being shared. Again, if the person is already logged in to their OpenID provider, this is a one-click step!

[[File:openid_permission.png|center]]

By clicking accept, the OpenID provider redirects the user back to your site using the "return_to" field you provided the OpenID library see step 5 in the OpenID workflow diagram above). At this point you have identified the user by their email. What does this mean exactly? Well, anyone can setup their OpenID provider so this doesn't provider any email verification. So the person claiming to be "president_barack_obama@whitehouse.gov" from OpenID provider X doesn't mean he/she actually owns that email, but you can uniquely identify them as that person claiming that email from that OpenID provider.

== Show Me the Code ==

Sounds great, right? What does this actually involve on a developer's part? While the protocol is relatively complex most web frameworks already have one or possibly several OpenID libraries you can use. Take [[http://www.tornadoweb.org/en/stable/ Tornado]], an asynchronous web framework written in python as an example. It's OpenID implementation is actually built into the framework (framework developers take note--this is awesome)!

Tornado provides a variety of mixins for authentication and includes one specifically for Google's (this includes the hard-coded OpenID url described earlier) called [http://www.tornadoweb.org/en/branch2.3/auth.html#google GoogleMixin]. Let's take a look at their example handler to see how it works. I won't go into the nitty-gritty of how tornado works.

<code>
class MainHandler(tornado.web.RequestHandler, tornado.auth.GoogleMixin):
@tornado.web.asynchronous
def get(self):
if self.get_argument("openid.mode", None):
self.get_authenticated_user(self.async_callback(self._on_auth))
return
self.authenticate_redirect()
def _on_auth(self, user):
if not user:
raise tornado.web.HTTPError(500, "Google auth failed")
# Save the user with, e.g., set_secure_cookie()
</code>

What is this code doing? Well, first in the ''get'' function it checks whether there's an "openid.mode" argument in the request. If there is, that means this request is coming from the OpenID provider. On the first try it's not so let's go down to function ''authenticate_redirect''. That will actually redirect the user to Google's provider url. If you look at the code for this function, it actually includes a "next" parameter which tells Google to send the user back to this url when he/she is done authorizes or denies the request.

The OpenID provider should redirect the user back to this handler and this time the "openid.mode" argument should be set. ''get_authenticated_user'' actually parses the response of the data and sends it to a callback function (''_on_auth'' in this case) with the user data. ''_on_auth'' checks whether the "user" field is not null. If so, the user accepted the OpenID request and you now know some information about that (like their email).

In this case we've hard-coded Google as the OpenID provider. What's the advantage of doing this? Well, if a user jumps to a page that requires identification, you can redirect them immediately to the Google OpenID provider and with one-click they're back on your site. How painless is that?

Well, what if you don't want to force Google as the OpenID provider? Tim explains some people have actually added some additional logic to see which OpenID providers the user has available and chooses one of those. Again, one click for the user and you get your juicy identification. No one gets hurt.

== Conclusion ==

Should you always use OpenID? In most cases OpenID is perfectly fine for many sites like forums or "toy" sites where verifying the person's actual identity isn't necessary. You'd still have to do things like email verification if that's important to you. There are, of course, some cases where a username/password are required and it's fine to use them instead. Just remember that if go that route you're causing your users pain and cost you time and resources to keep them secure. Make sure it's worth it.

Security Tips

2014-07-31T15:15:58Z

Strattonbrazil: Created page with "my personal notes on security ** personal email password ** storing passwords, custom solutions"

my personal notes on security

** personal email password

** storing passwords, custom solutions

Writing Tips

2014-07-30T07:29:31Z

Strattonbrazil: /* 7 Tips to Improve Your Writing */

In the last few years I've become very interested in art of writing. Below are a collection of random sources I've been learning from. It's rather humorous to read a lot of these authors as they often point out a novice mistake and I instantly realize, ''"Yep, that's me she's talking about."''

== Constance Hale ==

Constance Hale gets her own section because I love her book, [http://www.amazon.com/gp/product/0385346891/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0385346891&linkCode=as2&tag=strattonbrazi-20&linkId=367AOLVLLXSSRZDZ Sin and Syntax: How to Craft Wicked Good Prose]. The book is very practical and well organized enough to serve as a reference. Each section includes snippets from some classic authors that provide excellent contextual examples of a given idea she's explaining. It's a book plan to reread several times just to keep all its contents fresh in my head.

I also read her other book, [http://www.amazon.com/gp/product/0393347052/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0393347052&linkCode=as2&tag=strattonbrazi-20&linkId=ICBU6OWOY6WNUSXI Vex, Hex, Smash, Smooch: Let Verbs Power Your Writing]. While I also enjoyed it, it was much drier and didn't provide as much practical information for a novice writer like myself. It has a large section dedicated to specific misused verbs, which was a little too specific for my level but probably appropriate for beginning editors. I did find myself giggling at some of the bizarre and powerful prose she's included throughout the book.

In general I found myself agreeing to most of her suggestions. She emphasizes short, to-the-point sentences with strong verbs. Vex, Hex, Smash, Smooch in particular demonstrates the intricacies of verbs in the English language. She has a [http://sinandsyntax.com/ blog] and [https://twitter.com/sinandsyntax twitter account] where she regularly posts interesting tidbits on writing.

== 7 Tips to Improve Your Writing ==

This is an [https://www.youtube.com/watch?v=FHEAmAyMdG0 eight-minute clip] I found late one night by "Katytastic" that I found extremely practical. While its worth watching, I'm including her seven tips below.

{{#ev:youtube|FHEAmAyMdG0}}

====== 1. Show, Don't Tell ======

Avoid narrating things like emotions that could better be described visually. She recommends as a tool to write as if the words were expressing a movie scene with no narrator. Don't say something like, ''"He stood up angrily"'' when you could describe how one might perceive that he's angry (ex. he pushed himself up, his hands clenched into fists).

====== 2. Use Active over Passive Voice ======

As she reminds her viewers, this is something everyone hears all the time, but I still find myself naturally falling back on passive voice as I write. Constance Hale in ''Sin and Syntax'' actually details the appropriate times to use passive voice.

====== 3. To Be or Not To Be ======

This relates to the previous point, but as Constance Hale also states try to eliminate uses of "is, was, were, etc." replacing them with stronger, more descriptive verbs. She reminds viewers that its sometimes appropriate to use passive voice if the character in question is a very passive.

====== 4. Avoid Words that End in '-ly' ======

While adverbs aren't necessarily bad, Kat says these verb/adverb combos can often be replaced with stronger verbs. For example, ''walked lazily'' could be replaced with ''strolled'', ''meandered'', or ''ambled''. All convey the same idea but with fewer words. And as Constance Hale has frequently written, if you can convey the same idea in a shorter sentence, use the shorter version.

====== 5. Avoid Thinking Words ======

Again, this goes back to her "show, don't tell" philosophy to avoid words like ''thinking'', ''realizing'', or ''remembering''. "Don't have a character just realize something. Present those facts to the reader so they can realize it."

====== 6. Doubles are Troubles ======

Avoid using the same word over and over. Basic stuff but it happens all the time and is lazy.

====== 7. Choose Wisely ======

Be aware of every word you write. Be very intentional with every word you write. Sometimes you might fall into something great, but most of the time the perfect "incarnation" of a sentence will require thought and revisions.

Git in Government

2014-07-23T16:38:27Z

Strattonbrazil:

In November 2013, The Economist wrote a synopsis on [http://www.economist.com/news/united-states/21590368-why-congress-writes-such-long-laws-outrageous-bills Why Congress Writes Such Long Laws].

What would bills be like if would could track bill edits as we do in git?

<blockquote>''[http://www.economist.com/news/united-states/21590368-why-congress-writes-such-long-laws-outrageous-bills In 1948 the average length of bills that made it through Congress was two and a half pages. Now it is 20.]''</blockquote>

Main Page

2014-07-19T18:07:28Z

Strattonbrazil:

== Software Development Hiring ==

* [[Building Your Resume]]
* [[Interviewing a Technical Candidate]]

== Miscellaneous ==
* [[Using OpenID]] - why most sites should use OpenID instead of usernames and passwords
* [[Computer Graphics]]
* [[Writing Tips]] - my collection of useful writing tips, videos, and reviews
* [[Juniper Pulse on 64-bit Linux]]
* [[Roger Gracie BJJ Competion Breakdown]]

== Links ==

* [http://www.github.com/strattonbrazil My Github Page]
* [http://www.dotnet-tricks.com/Tutorial/designpatterns/2FMM060314-Understanding-MVC,-MVP-and-MVVM-Design-Patterns.html Understanding MVC, MVP, and MVVM Design Patterns] - I care extremely little for the whole MVC/not-MVC arguments, but I found this article helpful for those interested