I'm new(ish) to Laravel and I've been trying to get a clear understanding of how to use Faker to generate my test data. One of the things that's really confusing me right now is the different versions of Faker that I'm seeing in code examples. Some of them use fzaninotto/faker while others use fakerphp/faker (which I see is built into my Laravel 9.41.0 app).
What is the difference between the two packages and which one should I be using? Or will I need both due to differences between what fakes each package can generate?
I'd really appreciate some advice on this matter. I have a suspicion that the fzaninotto version is an older version of the fakerphp version and that I should simply use fakerphp and just think "fakerphp" whenever I see examples that use fzaninotto but maybe that is just wishful thinking on my part....
Related
Since Laravel 5.4, the default method to compile assets is using Laravel Mix, instead of elixir.
I know that "Mix" uses WebPack by default to compile the assets.
What benefits does this method bring?
The Mix also allows you to compile without WebPack, and this always
produces files that are smaller in size and work the same.
This is entirely incorrect. Have you attempted to configure any of the myriad options to optimize your bundle at all?
Start with the webpack-bundle-analyzer plugin. This will give you an idea where your bloat is, what is duplicated, and where to start trimming your application.
Between uglifying, chunking, deduplification, minification, etc. you'll have in the end compiled resources that are far from "large".
Now I'll grant you it has a steep learning curve comparative to other tools, regardless, WebPack is an incredibly powerful tool, you need to take the time to learn it's configuration capabilities.
Care to elaborate on what you mean by working the same? I run several production applications as well as a number of smaller personal projects. I never seem to get different results after each build.
But in the end it's just a tool. A tool like any other tool, you use what you feel comfortable with and what fits for the job. There's a reason it as selected as the default, though. And it isn't because the maintainers are ignorant by any means.
I have read through Q&A/articles that explain the ideal structure of a Ruby project. I read the RubyGems guides on how to create a Ruby gem. I have just read a Q&A asking at what point a ruby project becomes a ruby gem but I can not for the life of me see the difference between the two. The structure seems to be the same. The files, where they go, everything looks the same to me. Is it how they're used? Can someone please explain the difference between the two to me?
The question that must be answered respect to 'Gemify' or not is: am I writing something that is readily reusable in a different context? If the answer is yes then your application is a candidate for 'Gemification'. If not then generally it is not worth the additional complexity to convert a Ruby project into a Gem.
For example. If one makes a CLI Ruby application that collects mortgage rates from multiple vendors and updates a database then there are two ways this could be converted into a gem.
First: You could generalise the interface/configuration and make it useful as a plugin/add-on/extension to projects written by someone needing the same or similar functionality. So someone could add the gemified version to their project and use it to do the grunt work for them and just make use of the results. This describes the most common use case for gems.
Second: However, you could also extract the framework of your CLI project layout into a generator gem for others to easily create their own CLI project layouts. This is how Rails came to be.
I am not even sure how to ask this question. I am absolutely willing to research this myself, but I don't even know what exactly my options are.
I'm fairly new to programming in general, and I'm the sole developer on an ASP.NET MVC3 web application. We're about to upgrade to a new version which has a lot of addition to the data model. There are a couple new entities and some of the old entities have new properties/columns.
We've finished beta testing and now we're going to try to get everyone moved over to the new version running parallel to the current version, that way if there are show-stopping problems, users can easily switch back to the old version. The problem is that we can't hook both up to the same db because of the data model differences.
Can I make the old version use the new version's schema or something? I'm not really sure what my options are. I'm not asking you to write this for me; I'm just looking for some direction. Thanks!
You should be able to disable the metadata checks and then use two versions against the DB assuming the models use a schema that is compatible between both.
http://revweblog.wordpress.com/2011/05/16/ef-4-1-code-first-disable-checking-for-edmmetadata-table/
Another option is to use entity framework 4.3 code first migrations and actually use an upgrade script that it will generate for you. If it fails you can roll back the script to a prior version and use your prior code base. This would imply you upgrade to 4.3 first before doing anything else though although you could still disable metadata checks.
Recently CI 2.1.0 is out.
I have a question. As I recognized that the CI folder structure has been 'evolved' (easy to setup, automatically defines base_url,etc), I'm wondering if the current template libraries like Phil's,william's concept,ocular,etc.. can be adapted to this new CI version.
I've tried Phil's but no luck, I mean..I don't know if I'm missing something this time, and ocular, also, to no avail ( I don't subclass the Controller, as suggested here)
Any better templating suggestions that will be suited enough to the latest CodeIgniter 2.1.0?
Thanks.
It seems like from the comments above that you're having trouble finding any resources online on the matter. Here's my suggestion for you:
Check the CodeIgniter Change Log here, and compare all the changes between this newest release, and the release that you know last worked with the template libraries that you've mentioned above. Use deductive reasoning, and see if you can find a way to modify the templates you need to work with the current CodeIgniter structure. I know that's a lot of work, and is not ideal for your situation. Regardless, it's the best advice I can give at the current moment. Good luck, and happy reading!
i want to port my application to CodeIgniter but i am wondering whether i should use their v2.0 or v1.72 (then when they release 2.0, upgrade it).
i have never used a framework before so i don't exactly know what implies when upgrading a framework: what does it mean practically - i just move the folders and it will work? or do i have to change a lot of settings, file structure etc? could someone enlighten me about the upgrade process.
and what would you use: v.1.72 or v2.0?
if i'm using the latest version, is there a good documentation for it somewhere so you can read about how to use the new features: packages, drivers and so on.
thanks
You can read about some of the changes in 2.0 here.
I would image the upgrade process should be straightforward as long as you do not use any features that are different/removed such as plugins. Just take your models, controllers, etc and drop them into the 2.0 framework. Then regression test you whole app, fixing any problems as you see them...
If you are selling this app or making something mission critical then of course v1.7.2 is the best choice. That said I have PyroCMS running on v2.0 and since some of my bug-fixes were merged it seems stable enough.
One should consider time frames for deployment:
If it is one week, then stick to v1.7.2
If it is three months, go with v2
Assuming three months is approximately to time for a release to stabilise?