archive-com.com » COM » B » BENRAMSEY.COM

Total: 425

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Post-Open Source, by Ben Ramsey
    shift since 2000 in favor of more permissive licenses MIT BSD etc and surmises this could be the result of corporate influence allergy to GPL or a reaction against the GPL favoring freedom of developer over freedom of users Why are so few repositories adding open source licenses Luis Villa posits it might be because developers are rejecting permission culture The open license ecosystem assumes that sharing can t or even shouldn t happen without explicit permission in the form of licenses What if post open source is an implicit critique of that assumption saying in essence I reject the permission culture So when James Governor posted in September 2012 his sentiment about younger developers being about post open source software it was perhaps a bit of tongue in cheek crotchety cane shaking about a cultural shift in developer attitudes toward open source and the need to grant permission younger devs today are about POSS Post open source software fuck the license and governance just commit to github Rising Abovit monkchips September 17 2012 If we re in a post open source era and open source licenses represent permission granted to use one s code then is this era marked by a reaction against the need for that permission After all the younger devs grew up in a post Napster world full of DRM EULAs IP copyright lobbyists and legalspeak about what we can and cannot do with the content and software we ve purchased Open source licenses are yet another way to proliferate that permission culture It s no wonder there s a backlash against the need for licenses In Lawrence Lessig s 2004 book Free Culture Lessig warned Free cultures are cultures that leave a great deal open for others to build upon unfree or permission cultures leave

    Original URL path: https://benramsey.com/blog/2016/04/post-open-source/ (2016-04-26)
    Open archived version from archive

  • Introducing ramsey/uuid, by Ben Ramsey
    due to other packages using the older 2 x series When UUIDs Collide Shortly before the GA release of 3 0 0 I received a troublesome bug report Issue 80 purported to show that version 4 UUID collisions were occurring on a regular basis even in small scale tests and as I mentioned earlier this should not be probable After several more corroborating reports we were faced with a conundrum Since I couldn t reproduce the issue and no one could produce a sufficient reproducible script the issue sat around for a long time Every couple of weeks or so someone would chime in to ask the status or confirm they had seen collisions It began to scare people and I was worried that community confidence in the library was degrading I was actually stressed by the whole situation I wanted my library to be useful and dependable Finally after many months attempting to identify the culprit I was certain it wasn t inside the library s code since ramsey uuid relies on external random generators I had a conversation with Willem Jan Zijderveld and Anthony Ferrara in the phpc channel on Freenode IRC Willem Jan pointed us to the OpenSSL random fork safety issue where the OpenSSL project explains Since the UNIX fork system call duplicates the entire process state a random number generator which does not take this issue into account will produce the same sequence of random numbers in both the parent and the child or in multiple children leading to cryptographic disaster i e people being able to read your communications OpenSSL s default random number generator mixes in the PID which provides a certain degree of fork safety However once the PIDs wrap new children will start to produce the same random sequence as previous children which had the same PID They go on to say OpenSSL cannot fix the fork safety problem because it s not in a position to do so OpenSSL was the culprit More specifically the use of openssl random pseudo bytes when using PHP in forked child processes as is the case when using PHP with Apache or PHP FPM The processes were wrapping so the children would produce the same random sequences as previous children with the same process IDs Discovering this launched discussions on what to do about OpenSSL for the paragonie random compat library After that project decided to drop the use of OpenSSL as a fallback for generating random bytes I decided to require paragonie random compat as a dependency and use random bytes as the default random generator for ramsey uuid I then released versions 2 9 0 and 3 3 0 to provide versions in both 2 x and 3 x to solve this problem ramsey uuid 2 9 0 3 3 0 fix the UUID collision issue caused by OpenSSL All users should upgrade Thanks https t co N6Rwz1a5e2 Ben Ramsey ramsey March 22 2016 It s interesting to note that SwiftOnSecurity picked

    Original URL path: https://benramsey.com/blog/2016/04/ramsey-uuid/ (2016-04-26)
    Open archived version from archive

  • Hour of Code, by Ben Ramsey
    Hour of Code during Computer Science Education Week this year She had never done the Hour of Code and had requested a volunteer to help out I was to be the one leading the entire program No problem Winging things is my specialty So that s what I did I spent a few minutes telling about what I do as a programmer on a daily basis and I quickly realized that while I m passionate about what I do it can sound rather banal when being explained to others so I switched gears I told them a brief version of my origin story so to speak I began with a question Who has ever written code No one raised their hands so I pressed on I wrote my first computer program when I was in fourth grade It was a Mad Lib generator The students seemed to perk up and get interested at this I continued with my brief introduction to tell them that I went on to build my high school s first web site back in 1995 but I never saw programming as a career It had always been a hobby for me Then I stumbled into a job building web sites and doing sever side programming while I was still in college It wasn t until a professor convinced me to keep my job and drop the education requirements of my degree student teaching etc that I began to see my hobby as a career I wanted to impress upon the students that careers don t have to be boring things they can be the things we are passionate and excited about The things we enjoy doing in our free time are things that we can do for a living From there I had them open up code org on their Chromebooks and click the Start learning button They chose the Learn an Hour of Code exercise that appealed most to them and proceeded to complete the steps Some students breezed through the activities while others struggled with the concepts I used this as a teaching point since my primary goal was to teach the students that failure and trial and error are natural parts of coding If something doesn t work the first time then keep trying until it does work Sometimes it takes many attempts before you get it After Kathy asked me several questions about the history of programming I decided to wrap things up and try to answer her questions in a brief review of what the students had learned I asked them what their favorite part of the exercise was and what they felt the most difficult part was The answers varied Then I introduced a tiny bit of computer science history with a discussion of ENIAC bugs and Grace Hopper By then our hour was up and it was time for the students and myself to go The time had been all too short but I will volunteer again and I

    Original URL path: https://benramsey.com/blog/2015/12/hour-of-code/ (2016-04-26)
    Open archived version from archive

  • Yak Shaving Is the Entire Job Description, by Ben Ramsey
    as a programmer every task was fraught with problems and I loved it Everything was new and every problem was an opportunity to learn and grow It was great Somewhere along the way though problems became nuisances As I grew older in life and my career my tolerance for problems became lower and my desire for things to Just Work became greater As I struggled to find a solution for the problem I had with Packer Tate Eskew reminded me that yak shaving is a part of my job teskew i d just patch it then keep it in a central place so you only compile it once then when it s put into mainline just switch out the binary teskew either way it s a pretty simple patch to test and change ramsey ugh gotta set up an environment just to build packer ramsey simple teskew you act like yak shaving isn t the name of the game ramsey P teskew hell it s the entire job description teskew ramsey I am not an ops person teskew you are right now I ended up patching Packer for my needs and I had fun doing it I learned a valuable

    Original URL path: https://benramsey.com/blog/2015/11/yak-shaving/ (2016-04-26)
    Open archived version from archive

  • Lack of Hypermedia, by Ben Ramsey
    problems I thought it might be helpful to post my full response which follows One of the most common problems I see in API development is lack of hypermedia or none at all By hypermedia I mean links that describe relationships among data in the API When hypermedia isn t used the API becomes brittle and those building clients that talk to the API are forced to code to URLs The URLs become an important interface to the API and if they change they break everything This leads to URL based versioning schemes and the only upgrade path for clients is to modify their code to accommodate the new versions When an API uses hypermedia the URLs are no longer important Clients talking to the API do not need to code to URLs because the API will always convey where to go next through hypermedia relationships If a URL changes then there s no problem The change gets communicated through the API This leads to a more flexible and evolvable API that can change over time without needing to update all the clients I gave a talk at True North PHP this year that covered this topic The slides are

    Original URL path: https://benramsey.com/blog/2015/11/lack-of-hypermedia/ (2016-04-26)
    Open archived version from archive

  • Día de Muertos, by Ben Ramsey
    your own remembrances for these Richard Cyberlot Thomas I met Cyberlot first online in the phpc IRC channel on Freenode I saw him at occasional conferences and I was sad to hear of his death in November 2010 He was an active contributor to the Solar framework project Shortly after his death Jeff Moore wrote a post remembering Cyberlot Nick Jones Nick was founder of the PHP Fusion project The PHP Fusion project maintains a book of condolences remembering his life and contributions Jeff Surgeson Jeff was a contributor to the Aura and Solar framework projects Richard Lynch Richard was one of the first people I met in the PHP community having interacted with him a great deal on the php general mailing list He founded the Chicago PHP user group and was always willing to help newcomers with questions Jefferson McCree Jones I met Jefferson first on IRC in the phpc channel He attended the second PHP Appalachia and I began taking him to Atlanta PHP meetings We were roommates at a number of conferences and his enthusiasm for technology and jovial attitude touched many Jefferson was a great friend I miss him dearly Mike Dugan Mike was an

    Original URL path: https://benramsey.com/blog/2015/11/dia-de-muertos/ (2016-04-26)
    Open archived version from archive

  • Dates Are Hard, by Ben Ramsey
    It s not an arbitrary choice Version 1 UUIDs are based on timestamps that are created from 100 nanosecond intervals since 00 00 00 UTC on October 15 1582 Again UUID doesn t arbitrarily use this date It s an important date in history It is the first day of the Gregorian calendar For my unit tests I chose to test a few of the earliest dates that could possibly be used to create UUIDs I chose to use static date strings since I didn t expect the dates to change I used PHP to generate the date strings in RFC 2822 format php var dump gmdate r strtotime 1582 10 16T16 34 04 00 00 string 31 Sun 16 Oct 1582 16 34 04 0000 And my tests included code that looked like this uuid Uuid fromString 0901e600 0154 1000 9b21 0800200c9a66 this assertInstanceOf DateTime uuid getDateTime this assertEquals Sun 16 Oct 1582 16 34 04 0000 uuid getDateTime format r Using these date strings I was under the mistaken impression that systems know on what day of the week any particular date is supposed to fall The system on which I ran this PHP code was convinced that the 16th of October in 1582 was a Sunday so I trusted this The 16th of October in 1582 was not a Sunday however It was in fact a Saturday And the 15th of October in 1582 was not a Saturday as these same systems reported but rather a Friday When Travis CI reported two of my builds as broken it was because these systems were accurately reporting the day of the week It gets stranger though The Unix cal program doesn t seem to know the correct day of the week for these dates either cal 10 1582 October 1582 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 What s going on here To make a long story even longer Gregory s calendar reforms sought to correct a drift in the date of the vernal equinox and to correct this shift and place it back on March 21st ten days were removed from the calendar at the time of adoption of the Gregorian calendar Thus October 4 1582 falls on a Thursday and the very next day is October 15 1582 which is a Friday The Unix cal program doesn t show this removal of dates in October 1582 so dates 5 14 are still in place As a result how can we be certain that our current days of the week fall on the correct dates It s clearly wrong Where does Unix cal fix this It turns out the Unix cal program follows Great Britain s adoption of the Gregorian calendar Great Britain and its American colonies at the time adopted the Gregorian calendar in September 1752

    Original URL path: https://benramsey.com/blog/2014/02/dates-are-hard/ (2016-04-26)
    Open archived version from archive

  • Chicago PHP First Met in 2000, Not 1997, by Ben Ramsey
    of the community Most recent I published it in an InfoWorld article reflecting on PHP at 20 years However today this fact was called into question and debunked because John Long happened to link to an old mailing list post from 2000 In the post dated February 26 2000 Richard Lynch says The first Chicago PHP User s Group CHIPHPUG CHIF pug meeting went very well It was originally announced as MPUG but even I didn t really like that name It was just convenient After seeing this I assumed the year must have been wrong I thought maybe Grokbase had a bug but then John pointed to the same post on news php net After this I did some more exploring only to find a post dated February 23 2000 where the very first Midwest PHP User s Group meeting was announced The language used in the post was very similar to that found on the historical page it s missing the year The very first Midwest PHP User s Group meeting is definitely on Saturday February 26th 1 pm CST Ignition State This post also links to http www L I E com MPUG htm a page on Richard s domain I looked up this page on the Internet Archive to find that it is identical to the historical reference page that used to be hosted at chiphpug php net with one exception The year 1997 was erringly added to the historical reference page To confirm I found the very first Internet Archive capture for chiphpug php net where it identifies the first meeting of the Chicago PHP user group as Saturday February 26 2000 It turns out February 26 1997 was a Wednesday while the historical reference page identified it as a Saturday further proof the year

    Original URL path: https://benramsey.com/blog/2015/07/chicago-php/ (2016-04-26)
    Open archived version from archive



  •