Jump to content

owlmanatt

Programmer
  • Content Count

    12
  • Joined

  • Last visited

  • Days Won

    2

Daily XP Streak Bonus

XP

Start posting to receive your Daily Streak Bonus for your Adoptable. Every day you post, the more XP you earn.


owlmanatt last won the day on October 28 2017

owlmanatt had the most liked content!

Community Reputation

10 Good

About owlmanatt

  • Rank
    Member

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Bootstrap swapped to SASS for v4. I'm using that on all my stuff (it's still beta, mind), so SASS is the path of least resistance.
  2. I didn't hate it, but I like this better.
  3. I have to agree with @HappyDemon's assessment -- it's underkill for my purpose. I saw it was labeled as the microservice edition of Laravel, but what I'm doing stretches the definition of microservice considerably. With that said, getting Facades and Eloquent turned on is easy and supported out of the box. Regaining the other bits of Illuminate is fairly simple too, but perhaps not a good idea long-term -- making it easy to turn Lumen back into Laravel is probably not something Otwell is concerned with, so I expect it will cause at least some pain down the road. The immediate problem is the Passport shim. I want a full-blown OAuth provider, but right now I'm missing the authorization / scope management stuff because Lumen doesn't do views. In the spirit of ~servicing all the things~, I'm probably going to split the OAuth provider into its own stand-alone Laravel app at some point, as well as cutting auth data and separating it from my main `users` table to preserve sanity (auth site manages auth data, game API manages all the other bits of user). In retrospect, I probably should have just gone with Laravel. It's not really that hard for me to swap over, but I think I have all the Illuminate functionality I need now, so I'll keep on trucking and see what happens. Lumen really shines for actual microservices -- I started working on a stand-alone imagicking service (which is, at the moment, perhaps the most over-engineered compositeImage call ever) -- and it was frictionless.
  4. Chris Fideloper released the first section of his new webcast series, Performant Laravel, this morning. Included was a really good introduction to indexing your database tables. If you're unfamiliar with this topic, I highly recommend giving these three videos a run through: https://serversforhackers.com/laravel-perf/mysql-indexing-one https://serversforhackers.com/laravel-perf/mysql-indexing-two https://serversforhackers.com/laravel-perf/mysql-indexing-three While it is a series about Laravel, these concepts are useful even if you're using another framework, or no framework at all. He is demonstrating on MySQL, but indexes work the same in Postgres, MariaDB, MS SQL Server, etc.
  5. Here's another thing that had been vexxing me for awhile: Passport keeps some encryption keys in the storage/ dir. It requires the permissions be set to 600 on the files so only the owner can read the keys. I'm running Apache instead of the built-in dev server, so these key files are owned by my apache user so authentication will work. The problem is when I'm running unit tests, a bunch of test cases would fail because Lumen would try to verify the bearer token as a valid session. Since these are running as me and not Apache, Passport would get an access denied for the keys and throw an exception. The solution is actually pretty easy -- generate a new keypair for unit testing and stick the keys in a new dir under storage. Then, in your base class for your unit tests: public function setUp() { parent::setUp(); // If you're using this as a dev env, you might have Apache as the owner on the files for the default location. Passport::loadKeysFrom(storage_path('phpunit_passport_tokens')); } I think this is just for signing the tokens, so it has no relationship to the client secrets that get stored in the DB. I, uh, am not entirely sure if that gets created when running the unit tests...? But with actingAs(), all the authenticated requests are just using a mocked guard provided by Passport, so no big deal I guess?
  6. The `calz` binary should be in your shell's $PATH. $PATH is a list of folders it'll check for executables, which is what allows you to just type calz. You have two options: you can move it to a folder in $PATH (run `echo $PATH` to get the list), or you can add another dir to $PATH. nevans@chi:~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/nevans/.composer/vendor/bin/ nevans@chi:~$ cd test_913/ nevans@chi:~/test_913$ ls dummy_executable # This is the problem nevans@chi:~/test_913$ dummy_executable -bash: dummy_executable: command not found nevans@chi:~/test_913$ ./dummy_executable Hello world! I have run successfully! # Solution 1 - move it somewhere in the $PATH nevans@chi:~/test_913$ sudo cp dummy_executable /usr/local/bin [sudo] password for nevans: nevans@chi:~/test_913$ dummy_executable Hello world! I have run successfully! nevans@chi:~/test_913$ which dummy_executable /usr/local/bin/dummy_executable # Solution 2 - add a new folder to the $PATH. nevans@chi:~/test_913$ echo 'PATH="$PATH:/home/nevans/test_913"' >> ~/.bashrc nevans@chi:~/test_913$ source ~/.bashrc nevans@chi:~/test_913$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/nevans/.composer/vendor/bin/:/home/nevans/test_913 nevans@chi:~/test_913$ dummy_executable Hello world! I have run successfully! nevans@chi:~/test_913$ which dummy_executable /home/nevans/test_913/dummy_executable Note that solution #2 is only adding that dir for your current user. If the webserver needs to add an entry to its $PATH, that'd be a mite bit different.
  7. I've seen some mention of Laravel around these parts. I'm doing something with Lumen, which is Laravel's micro-framework edition, so I thought I'd post some thoughts on the two. As I said, Lumen is a micro-framework. The primary use-case is for building REST APIs, so everything to do with templates has been pulled out of Lumen. Out of the box, Lumen doesn't have a bunch of the libs you find in Laravel either -- Eloquent is disabled, mail is disabled, and there's no config/ dir. However, all of this can be re-enabled if you need it. What I'm doing with the framework is building the backend for a pet game. Separately, I'll have the UI as a single-page javascript app, and 3rd party forum software. I thought Lumen would be ideal for this, but I ran into a few problems: 1. My API is the authentication source for the UI & forums. I wanted to implement an OAuth provider, which is trivial in full-on Laravel -- they have Passport, which integrates the very-good League OAuth provider code into the framework. Lumen, however, strips this out! The challenge isn't insurmountable, though. I took a look at the Passport code and started thinking about what it would take to make it play nice with Lumen. It has some things that aren't part of the API authentication flow -- mainly, views for authorizing other apps. Fortunately, I typed some words into the googles machine at this point, and discovered that somebody had already solved the problem: https://github.com/dusterio/lumen-passport This is working fine for me, so far. In the future, if I want to enable other apps to get API keys for a user's data, I might need to extract the OAuth provider from the main game API and deploy a small Laravel site that just runs passport. 2. The ReCaptcha lib for Laravel has some views in it, boo. I wrote a quick wrapper for the PHP ReCaptcha lib. This might actually be useful to somebody else, so splitting this off into a standalone package is on my todo list. The site worked, but my unit test started failing. I don't really want to test the ReCaptcha code from google, so I had to mock the library. Initially, when I had written my wrapper, it was just a class. In order to get it to play nice with Mockery, I had to turn my class into a facade. This took a bit to figure out -- strangely, there wasn't that much up-to-date documentation on how to add your own facade to the framework. 3. There was no config/ dir. Because Lumen's focus is on being small and simple, I guess they decided not to have that out-of-the-box anymore. That's all well and good until you enable something that expects to find a config... Fortunately, all they did was not create the folder by default. If you make the directory and drop files in, they'll get picked up by both the framework and any 3rd party plugins. 4. Lumen was missing major bits of illuminate (the supporting libs for Laravel & Lumen) that I wanted to use. The biggest one was Eloquent, but turning that on is trivial; there's a line commented out in the bootstrap.php file. Turn it back on and your ORM is in business. My API is handling user signup and forgot password requests. Unfortunately, Lumen doesn't come with Illuminate/Mail. That one is a little trickier to re-enable: you've got to add it to install it with composer, register the MailServiceProvider, create a config file, and load the config in bootstrap.php. The mail thing is another reason I'm thinking about cutting the OAuth provider out of my API and moving it to a dedicated auth provider laravel project. Anyways, that's about it for my braindump. Aside from all the missing stuff, the final difference between Laravel & Lumen is that Lumen controllers expect you'll be spitting out JSON instead of rendering views. It's quite pleasant, assuming that's what you want to do! So yeah. I'm happy to field questions about Lumen. You can check out my code if you're so inclined.
  8. I'm using Lumen (the microservice-y version of Laravel), but I've successfully updated to 5.5. One thing I ran into: if you're using sentry to track errors, their plugin seems to not work right on the new version. It was inexplicably causing all of the Request objects that were injected into Guards to be completely devoid of request data, breaking auth. All of the controllers got perfectly good Request instances injected into them, so it's kind of a weird bug!
  9. ## Introduction Version control is the practice of keeping every revision of your source code. Using version control software will allow you to see changes over time and retrieve earlier versions of files. I'm sure that, before updating something, you've created a something_important.php.bk file that you can quickly restore. Version control allows you to manage this a little bit better -- we'll track every file and every change. If you create a bug and don't notice it for a few weeks, you can go back in time and retrieve an older copy of your code. This tutorial will explain how to set up SmartGit and create/use a git repository. We won't be using any 3rd party services like Github, Gitlab, or Bitbucket -- instead, our git 'server' will simply be a folder on your computer. Your code won't leave your hard drive. SmartGit is a graphical interface for managing a git repository. SmartGit is not the only option, though -- you can also check out GitKraken or SouceTree. I do not recommend the GUI that git itself ships with; it's a bit complicated for folks that are new to version control. I'll include some information about the other things you can do with git at the end of this guide. We're going over a very basic use-case, but it's also a powerful tool for collaborating with other developers. ## Setting Up Firstly, go and grab SmartGit -- it's free for non-commercial use. Once installed, it'll go right into the setup process. On the 'User Information' screen, feed in a name and email address. These are used when you 'commit' code to the repository -- it puts you down as the author of the changes. The other settings can be left as-is. Particularly, you want to leave 'Hosting Providers' set to "Don't configure a hosting provider for now" -- we don't want to publish the repository as an open-source project. After you've finished the setup screen, you'll get another popup asking what you want to do: Select the first option, 'Add blabla OR create a new repository'. This will allow us to initialize git. On the next screen, navigate to the directory with your source code, select it, and hit OK. The next popup will ask you if you want to initialize or cancel -- hit 'initialize': Initializing a new git repository here won't modify any of your files -- it will just add a folder called '.git'. And, of course, if you don't have any code yet, you can just make a new directory and initialize there -- as soon as you've written some code, you can have git keep track of it! ## Committing Files Initial setup done, you'll be greeted with a screen showing you all of the files in the folder. You'll notice the 'State' column says 'Untracked' for all of your files. There are a few states things can be in: - Untracked: git isn't keeping track of changes to this file (yet) - Modified: git tracks the file, but you've recently made changes that git has not added to its history for the file - Deleted: you've deleted a file git was tracking - Staged: by selecting a file & clicking 'Stage', you've queue it up for committing In order for git to do version control on a file, you have to instruct it to track that file. Similarly, whenever you've finished making changes to a file, you have to tell git that the new copy is ready to be added to the repository. Both of these things are accomplished by 'committing' your changes. Click on the 'Commit' button up top and we can get the current versions of these files tracked. You'll get a popup with all of the files. First, check off what you want to commit, then type in a 'commit message' -- this is a little note about what/why you changed things. The message will show up in the history, making it easier to find a certain change if you ever have to refer back to it. After committing the files, you'll notice they disappear from SmartSVN's file list. Don't worry; your files haven't gone anywhere. The reason they've disappeared is because git's current version of the file matches what's on your computer -- it only shows files that you might want to commit. Go and make a change to one of the files you committed. It can be as simple as changing one letter. It'll reappear in the list with the state 'Modified'. If you click on a 'Modified' file, the pane in the middle will show you the differences (or 'diff') between git's version and your new version. Every single line of code you've changed will be highlighted for you, so you'll know exactly what changes were made. Just as before, you can click 'Commit' to submit the new file to git. Note that if you've got file(s) seletced in the main SmartSVN window, clicking commit will limit it to just those files -- un-highlight them if you want the full list of files in the 'Commit' popup. From now on, you'll need to remember to commit your changes. It should only take a few moments, but since it's a new habit you have to get into, it might be useful to put a post-it on your monitor reminding you to commit your changes! ## Looking at History You can look at the diffs for every commit by hitting the 'Log' button. If it's greyed out, click your repository on the left-most pane first. In the log window, you can see the changes files & their diffs. For the most part, this is probably enough information for you to revert. However, maybe you don't quite recall when you last changed a file, and you need to look at what the code was like last month. In this case, it would be useful to look at just the log for that file. To do this, press ctrl+1, or click on the white page icon to the right of the 'File Filter'. Your SmartGit view is now showing you all of the files in your project. Find the one you want to see the history of, right click, and view the log. ## Conclusion You've now got an idea how to keep track of your changes with git, congratulations! The setup & process described by this guide is very simple -- you're tracking your own changes, one by one, in a nice neat line. Git is capable of a lot more than this. You can do things like: - Branch. You can create independent copies of your code to work on. Say you want to start a big project that'll involve updating lots of files. You expect it'll take a month. You could create a branch in git for the new feature & commit changes there. In the mean time, if you need to fix a bug on the live version of your site, you could swap back to your 'master' branch -- it won't have any changes for your new feature yet -- and fix it there. Once you're done with the feature, you'd 'merge' that branch into master and update your site. - Collaborate. Git allows you to sync your code up with other developers. Services like Github make this even easier with features like pull requests. Here are some newbie guides that go into more detail than the one simple use-case we've covered. https://www.atlassian.com/git http://rogerdudler.github.io/git-guide/ https://help.github.com/articles/git-and-github-learning-resources/ And, finally, you don't have to use git to manage just your code. You can version documents (which is what I did for the screenshots here) or images too!
  10. Hi, I am owlmanatt and I joined on 09/09/17! View Member
  11. owlmanatt

    Unknown

×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Terms of Use, and Privacy Policy.