|
musclecoder posted:I feel the exact opposite with Symfony (and Doctrine to a lesser extent, which I have a love/hate relationship with). It's completely changed how I build apps, and has allowed me to get many high quality, tested, in-depth projects out into production over the past three years. I'm definitely in this camp. With my adoption of Symfony (and Doctrine) I've learnt a great many tricks and where to place very firm demarcation lines and separate responsibilities in my code. For that effort I get code that's easier to maintain, test, and alter when people start telling me things ain't workin' right, or the business needs change. Of course, this has come at the expense of having to learn their individual limitations, requirements, and xdebug the tits off everything that makes me go "oh that's strange.." or "why can't I do that..", but I don't consider that a bad thing. I feel I'm a better programmer overall because of it, and I'm no longer working with black boxes and limited by the code documentation (or lack thereof). I've also learnt what not to do, and what patterns not to use because they're loving hard to understand when you're debugging. That absolutely isn't my day-to-day, but it's most definitely a strong aspect of how I go about solving my problems. Something I've come to understand over time is that your abilities are directly related to what you invest your time on. With code a lot of people don't realise that this also applies to whatever framework you're using on top of the base language. You can't expect to make flawless masterpieces from the get-go. There's going to be pain, confusion, and a learning period. Also, all cookbooks suck. When that framework is as retarded-huge as Symfony, sometimes you have to just trust the darkness - that black spot in your knowledge - that it's going to work correctly. And sometimes you have to take your flaming torch and go exploring. I see a lot of problems coming out of my team because they hit a limitation or restriction in the framework and won't create something to work around it, hook into the edges, and use the more complex tools. I've seen ungodly arrays and json decoded data structures just to work around a problem that can be fixed with a Form Listener. I don't blame them, there's a mammoth of documentation and no time to learn the tricks, but you need to get a feel for when you're actively fighting the framework rather than working around the problem. When you fight the framework you aren't solving problems, and you usually need to take a step back from your approach and figure out what you want to achieve, what you have, and what you need to create to get there. And then you need to code good, test, and leave enough freedom that you're not just adding to the problem for the next person.
|
#
?
Feb 5, 2016 08:51
|
|
|
|
| # ? May 16, 2024 11:19 |
|
|
hedgecore posted:Is there a modern, free solution to convert some HTML/CSS to a PDF through PHP? http://www.tcpdf.org/ or http://wkhtmltopdf.org/ and then use it via proc_open. Myself I've used both wkhtmltopdf (results are similar enough), tcpdf (outdated, tables layout becomes garbled as far as I can remember). You can also parse the DOM and then cater for specific elements using Zend_PDF (done that when positioning had to be print perfect). canis minor fucked around with this message at 12:16 on Feb 5, 2016 |
|
#
?
Feb 5, 2016 12:09
|
|
|
duck monster posted:it really needs to swap out its shity regexy template thingo for something like Twig or even Smarty. For *small* sites its great.)  You're insane. As someone who regularly maintains Laravel and Smarty apps, I would never in a million years prefer Smarty to Blade. Also can't you integrate Twig into Laravel in like 5 minutes if you really want it? Though I really don't "get" templating engines in PHP. PHP is a templating language. Why bother with @foreach $thing as $thing when you can just do foreach($thing as $thing)? It makes no sense other than to coddle designers from having to learn basic syntax (which ends up being the same). Also speaking of PDFs and Laravel, I've got wkhtmltopdf integrated as a composer package and it is really nice. I can basically just call a single line to output a view to PDF. One of the cool tricks I did on my last app, which is a reporting site, is I set up a system wherein it uses the same views for HTML as it does for PDF, with some additions and removals of code. Makes it extremely easy to add new reports to the app and I only have to write one view and be done. Combined with proper ORM setup and template wrappers, I can add new stuff to the app in hours if not minutes. I just finished a project that was slated to take a week and I probably spent 2.5 hours on it start to finish.
|
|
#
?
Feb 5, 2016 15:38
|
|
|
Re: Laravel + PDF I use https://github.com/barryvdh/laravel-dompdf which is what generates my TOS and AUP as downloadable PDF documents: https://lithiumhosting.com/terms_of_service (very bottom right) The content is in a single view, I load a different view that wraps the content view. php:<?
return View::make('terms.html.tos');
?>To generate the PDF, I just use a different wrapper view that extends a pdf layout and then includes the basic tos view. php:<?
$pdf = PDF::loadView('terms.pdf.tos', ['from' => URL::route('tos'), 'today' => Carbon\Carbon::now()->format('j F, Y'), 'document_version' => trans('terms.tos_version')]);
return $pdf->download('lithium_hosting-terms_of_service.pdf');
?>
|
|
#
?
Feb 5, 2016 15:49
|
|
|
revmoo posted:Though I really don't "get" templating engines in PHP. PHP is a templating language. Why bother with @foreach $thing as $thing when you can just do foreach($thing as $thing)? It makes no sense other than to coddle designers from having to learn basic syntax (which ends up being the same). My CTO has this exact opinion, and while I don't disagree, Twig/Blade at least make things like escaping sensible. Built in support for things like partials/extending layouts is also nice. I'm also a fan of syntax like foreachelse and unless. As with anything, you can do it yourself but why bother? PHP League's Plates is a good middle ground I guess.
|
|
#
?
Feb 5, 2016 16:33
|
|
|
revmoo posted:It makes no sense other than to coddle designers from having to learn basic syntax (which ends up being the same). Not all people that enter HTML are "designers." Our Marketing folks are brilliant in their own ways, but trying to explain the rules of HTML to a graphic designer that'd never really worked with it before was a nightmare. I wouldn't trust any of them with anything more complex than what a heavily sandboxed Twig provides, and wouldn't want any of them within ten feet of the actual PHP source code.
|
|
#
?
Feb 5, 2016 19:26
|
|
|
Well, that's when you use a CMS.
|
|
#
?
Feb 5, 2016 19:31
|
|
|
McGlockenshire posted:Not all people that enter HTML are "designers." Our Marketing folks are brilliant in their own ways, but trying to explain the rules of HTML to a graphic designer that'd never really worked with it before was a nightmare. I wouldn't trust any of them with anything more complex than what a heavily sandboxed Twig provides, and wouldn't want any of them within ten feet of the actual PHP source code. Yeah, I don't really agree with this argument. The ubiquitous presence of Wordpress all over the internet kind-of disproves the need to insulate people from the danger of using raw PHP as a template language. The quality can vary wildly, but if your designers are inexperienced in either php or <template-of-your-choice> then it'll still need sanitizing by a programmer regardless. If your colleagues really have that much trouble then you need to insulate them from code at all, and make them use a WYSIWYG embedded in the site (poor-mans-CMS) and feed the content through something like HtmlPurify to make sure it won't break anything else. revmoo posted:Though I really don't "get" templating engines in PHP. PHP is a templating language. Why bother with @foreach $thing as $thing when you can just do foreach($thing as $thing)? It makes no sense other than to coddle designers from having to learn basic syntax (which ends up being the same). The problem I see with most template languages is that you're asking most developers - who know PHP and HTML and JS already - to learn yet another language which will get compiled out to PHP anyway. It's the recurring CoffeeScript of the PHP world. If they have to think too hard or learn too much or fight around the system, then all it's doing is wasting time and making people angry, so in that way I fully support your views. That said - I do get the reasoning, and from a long-term maintenance standpoint it's a lot easier to work with code that looks like Markup then it does to work with markup that broken up by tons of code. revmoo posted:As someone who regularly maintains Laravel and Smarty apps, I would never in a million years prefer Smarty to Blade. I see Smarty as one of the least-useful template languages around, because (the last time I used it) everything Smarty does I can do in PHP, and all it does is make me jump through hoops and look up syntax. There was also a period where every project picked up Smarty in a best-practice panic, so now when I see a project that uses Smarty it raises a red flag for me, and I'm instantly cautious about the quality of the code in the rest of the site. Twig does have some very useful templating tools; you can design pages similar to Classes which include "blocks", and then inherit the main layout and swap out the blocks you want to. This can also be done in the smaller scale with "embeds". I'm not saying you can't do this with straight PHP, but the change in structure does justify turning it into a template language. Twig does make me unreasonably angry when I need to debug a template, though.
|
|
#
?
Feb 6, 2016 00:45
|
|
|
Heskie posted:My CTO has this exact opinion, and while I don't disagree, Twig/Blade at least make things like escaping sensible. Built in support for things like partials/extending layouts is also nice. I'm also a fan of syntax like foreachelse and unless. I've used this 40-line template engine for a few things. It's *bare* minimalism but gets some jobs done. Plates adds some functionality but works pretty much the exact same way. Did I mention it's only 40 lines of code?
|
|
#
?
Feb 6, 2016 12:31
|
|
|
There Will Be Penalty posted:I've used this 40-line template engine for a few things. It's *bare* minimalism but gets some jobs done. Plates adds some functionality but works pretty much the exact same way. This looks very similar to the templating layer our in-house micro framework uses. So much so that I'd be surprised if it didn't directly influence it.
|
|
#
?
Feb 6, 2016 12:50
|
|
|
The guy that created Plates did a talk at phptek last year, wherein he suggested using Twig. https://speakerdeck.com/reinink/enough-about-classes-lets-talk-templates
|
|
#
?
Feb 6, 2016 16:45
|
|
|
I have a php form that has a texa area. I want it to take the items in a list and separate each item as its own sql entry. Its not throwing any errors but it is also not sending the database. Ex: Bob Tom Chick John code:
|
|
#
?
Feb 11, 2016 20:19
|
|
|
joebuddah posted:I have a php form that has a texa area. I want it to take the items in a list and separate each item as its own sql entry. Its not throwing any errors but it is also not sending the database. Can you clarify what you are trying to accomplish? In your example do you want 4 insert queries (one for each "line")? If so: PHP code:
|
|
#
?
Feb 11, 2016 20:39
|
|
|
Thank you for your response. Yes I am wanting separate insert queries for each list item
|
|
#
?
Feb 11, 2016 20:59
|
|
|
Posting this here because I'm looking for PHP-specific advice. I recently lost my job, and it occurred to me that I don't have the one thing I always demand from job candidates - code samples. I have a bunch of half-done projects, but those are all code not fit to publish. I've discovered over the years that I tend to value things about code that many others don't, and the other way around. Time to seek advice. When getting a code sample from a job candidate, what qualities are you looking for? What are the things you aren't looking for? Do you care if it's a library or a stand-alone application, or if it's just a set of patches for other people's work?
|
|
#
?
Feb 12, 2016 22:32
|
|
|
The thing about prepared statements is you can do this:PHP code:
|
|
#
?
Feb 14, 2016 03:53
|
|
|
There Will Be Penalty posted:The thing about prepared statements is you can do this: Prepared statements also save the DB the trouble of re-running the query planner for each line. The parameters change, but the query remains the same.
|
|
#
?
Feb 15, 2016 17:51
|
|
|
rt4 posted:Prepared statements also save the DB the trouble of re-running the query planner for each line. The parameters change, but the query remains the same. This is only true when using real prepared statements. If using PDO, be aware that it only emulates prepares by default. You have to expressly set the PDO::ATTR_EMULATE_PREPARES attribute to false in order to get actual server-side prepared statements.
|
|
#
?
Feb 15, 2016 18:40
|
|
|
revmoo posted:Though I really don't "get" templating engines in PHP. PHP is a templating language. Why bother with @foreach $thing as $thing when you can just do foreach($thing as $thing)? It makes no sense other than to coddle designers from having to learn basic syntax (which ends up being the same). There's a lot more to Blade than you're giving it credit for.
|
|
#
?
Feb 15, 2016 20:34
|
|
|
I am working on familiarizing myself with Doctrine for a project where we are going to request a large amount of data from sources like CSV or the API for our CRM, process the data, and then import into our own database for reporting and other purposes. I followed their getting started tutorial (Doctrine + Symfony), which was fairly straightforward. However, they want this project to be in Laravel, so my understanding is that I need to rely on a 3rd party package like Laravel Doctrine. Their documentation seems to leave out some key pieces and what I'd really like is a good Laravel 5.1 or 5.2 + Doctrine tutorial. They also have a companion migrations library, which I haven't been too impressed with so far, but I'm still experimenting with it. know that Jeffrey Way says he doesn't intend to make a Doctrine Laracast and the discussion on the recent ORM discussion on PHP Roundtable seemed relatively dark on Doctrine for most use cases. So are there any better options for using Doctrine 2 with Laravel and if not, are there any good Laravel + Doctrine tutorials?
|
|
#
?
Feb 16, 2016 00:47
|
|
|
I'm not familiar with Laravel at all, but is there any reason you can't use their own ORM (Eloquent, I think it's called)? Doctrine with file feeds (or really any type of bulk processing, especially if it's data you don't control) can get really finicky. You need to ensure that your validation configuration is as tight as possible to avoid the "Entity manager is closed" exception if you attempt to flush an entity after an invalid query. Also, if your entities have a primary (or unique) key defined in the feed (like if you were importing users and the unique was their email address), having a unique constraint in your validator will be ignored the first time you attempt to write data to the database if you flush at the end of the import.
|
|
#
?
Feb 16, 2016 03:32
|
|
|
Not sure why you'd use that when Eloquent exists and is good. I wrote a billing portal in Laravel that pulls data from a TON of sources; remote DBs, memcached, remote APIs, local APIs, etc. Word of advice: keep everything as modular as possible. I broke each piece of data down into its own classes, and then wrote an artisan task that can run them separately or together, along with Laravel's scheduled task support for daily pulls. On the data storage side I used eloquent ORMs for each piece. So I have a) Data puller, b) Model, and c) Artisan task all broken out separate for each piece of the application. And boy am I glad I did. I recently had a new feature request that was way outside the box and it took no time at all to implement. Also find out at the very very beginning if you need to store history, and how much. I'm able to nuke my individual data sets and start over each time, but if you're expected to log changes things can get messy quick and you'll want to address it from the get-go.
|
|
#
?
Feb 16, 2016 14:23
|
|
|
There Will Be Penalty posted:The thing about prepared statements is you can do this: You are correct of course. Brain fart on my part.
|
|
#
?
Feb 16, 2016 16:33
|
|
|
revmoo posted:Not sure why you'd use that when Eloquent exists and is good. Yeah except it's an ActiveRecord implementation and ends up polluting your classes with things that the class shouldn't be responsible for. Data Mappers like Doctrine are worth the extra hoop jumping in order to make sure that the class stays as simple and focused on the task at hand as possible. There shouldn't be anything stopping someone from using Doctrine in a Laravel project. If the thing stopping you is Laravel having unchangable opinions about the way things should be, then it's more likely that Laravel is in the wrong than anything else.
|
|
#
?
Feb 16, 2016 22:36
|
|
|
McGlockenshire posted:Yeah except it's an ActiveRecord implementation and ends up polluting your classes with things that the class shouldn't be responsible for. I'm really not sure how Eloquent violates SOLID. Can you elaborate a bit further? My classes look pretty clean from here....
|
|
#
?
Feb 16, 2016 22:41
|
|
|
One thing that can be annoying with Eloquent is that it does not "support" compound keys. I've only ran into this issue a small handful of times, and ended up just writing raw queries for what I needed.
|
|
#
?
Feb 16, 2016 23:48
|
|
|
McGlockenshire posted:Data Mappers like Doctrine are worth the extra hoop jumping in order to make sure that the class stays as simple and focused on the task at hand as possible. Are they though? I understand its SOLID but what tangible benefit do you get by jumping through these hoops?
|
|
#
?
Feb 17, 2016 20:29
|
|
|
Testing? I don't even know. You can certainly test and mock Laravel models, so they're SOLID enough for that at least.... Programmers LOVE to over complicate and over-optimize the simplest things to the point of ridiculousness. See: using Mongo instead of Postgres, or using unit tests with weakly-typed languages.
|
|
#
?
Feb 17, 2016 21:07
|
|
|
revmoo posted:Testing? I don't even know. You can certainly test and mock Laravel models, so they're SOLID enough for that at least.... What do unit tests have to do with a language's typing?
|
|
#
?
Feb 17, 2016 21:12
|
|
|
If the problem you're trying to solve requires using unit tests on a weakly-typed language, you're approaching it from the wrong angle. If you have a mission critical system where bugs in production cannot be permitted at all, then you should be using a different language. Conversely, if your system isn't mission critical and you're putting all this big boy testing on top of it, you're wasting your time and your competitor is going to blaze right past you in the marketplace. Mind, I'm not saying testing is bad for PHP, but unit testing is a farce. Integration testing/regression testing is much more sensible and delivers a lot more value for the effort that it requires.
|
|
#
?
Feb 17, 2016 21:19
|
|
|
Thanks for the replies. I agree that Eloquent would be fine for this project, but they want to push ahead using Doctrine. I think part of it is that the previous version of the system was written in Symfony + Doctrine, so they have a comfort level with Doctrine, but want to get away from Symfony since it was a pain to configure and it would be nice to have all of our internal tools running on Laravel. Also, being able to use flush to more efficiently execute a ton of update and write statements is a very real concern for this project. There are other advantages too, but I'm still in the process of figuring out Doctrine, so I don't want to expound on a bunch of things that I'm still figuring out. I did some more searching around and found a set of slides about integrating Doctrine with Laravel that look like they might be better than some of the other documentation out there right now. I'm going to go over them this afternoon and see if that helps me get past some of the hurdles I've encountered. http://www.slideshare.net/MarkGarratt3/integrating-doctrine-with-laravel
|
|
#
?
Feb 17, 2016 21:55
|
|
|
revmoo posted:Not sure why you'd use that when Eloquent exists and is good. Eloquent, in my view , isn't even in Doctrines league, and doctrine itself is, in my view a bit of a mess. Eloquent falls apart when you start needing to do highly complex joins and then query across them, and I dont know if it can be fixed without fundamentally rethinking it. Doctrines not that hard to set up. app/console doctrine:generate:entities; app/console doctrine:migrations:diff; app/console doctrine:migrations:migrate and thats it to take nice YML specification of the model, poo poo out a POPO model with all the correct accessors, and then line it up with auto-generated migrations. Your DB is now reproducable. None of these hold a candle to monsters like Hibernate or the Django or Rails ORMs but for PHP , Doctrine seems to be the way to go. Doctrine does have a lot of faults, but it works well, and its YML->POPO->migration pipeline works drat well for getting complicated DBs out the door.
|
|
#
?
Feb 17, 2016 22:08
|
|
|
I started out with nothing, then PDO, then ADODB, then CakePHP's active record Models, and now I deal with Doctrine on a daily basis. Of all of these I prefer working with Doctrine, and my main reasoning is that the Entities and various other objects don't get polluted by the ORM once you're not using it. There's lots of other benefits like the tools, migrations, metadata mapping, logging, caching.. but when it comes to using the fucker I find the biggest benefits are in it's SOLID approach. Someone mentioned benefits; and the main one is being able to side-step, or avoid Doctrine entirely. Doctrine latches onto the entities, the entities are not Doctrine. It's possible to lift doctrine off the application and there's only a few tendrils (DQL, mostly) that need to be cut off. Perhaps it was the lack of documentation telling me how else to do it, but every incarnation of Active Record ended up a giant hell-beast of a Model class peppered with every possible query, or arrays of fields which made bugger all sense to an outsider and didn't debug nicely. One important aspect of an ORM is enabling you to work outside of it. SQL can do some silly weird poo poo, and people tend to build databases without thinking them though, which means sometimes you have to go back to basics and do a raw query. The most important aspect however, once you go off the rails, is to get back onto them as soon as possible. Migrate your lovely query result back into the respective entities and continue from there. When using an ORM, unstructured arrays are a plague that encourage other bad habits (like running updates directly back into tables outside of the ORM), and lead to unmaintainable and unreadable messes that are peppered with security issues. Having said all this, I do consider Doctrine to be very enterprise in the same way you'd call Zend or Symfony enterprise. It's big. It has lots of gotchas lurking deep beneath the surface. If you're in a rapid development environment with no space to learn or deep debug something (eg. an Agency working by-the-hour), or only writing a small scale application, I would probably suggest something easier and simpler to pick up - like Eloquent - over Doctrine. Aniki posted:I think part of it is that the previous version of the system was written in Symfony + Doctrine, so they have a comfort level with Doctrine, but want to get away from Symfony since it was a pain to configure and it would be nice to have all of our internal tools running on Laravel. Say.. what? I'm 100% in agreement with anyone who wants to point out that configuring Symfony and it's myriad of bundles with YAML or XML is one of the worst things I've ever seen introduced to a framework. The fact it all just compiles out to a static PHP file - but you can't have runtime config - makes me want to punch myself in the face until my eyes face backwards. However, you can rip the tits off Symfony and replace various parts of it, including the config system - so I don't really understand why you'd want to migrate a project off Symfony and go through the Netscape Navigator school of hard lessons just for a small sideways shift. I understand you've already got your marching orders, I just wouldn't go that route myself. revmoo posted:If the problem you're trying to solve requires using unit tests on a weakly-typed language, you're approaching it from the wrong angle. I don't really agree with this. Weakly vs Strongly typed languages only covers one tiny aspect of what can cause your system to catch on fire. I've seen poo poo in every language, and in some cases it's a complete miracle that they haven't exploded or overwritten adjacent memory. There's always going to be a trade off when you ascend the language levels of abstraction, but I don't believe reliability or quality needs to be one of those. Unit tests absolutely have their place. Between Unit, Integration and Acceptance tests they cover three different levels of functionality and granularity of your code. For example, say you have a shared pagination object and you want the setPage() method to always set the page to "1" if an invalid value is passed. You can make a test and have it flush a wide variety of data through setPage. Congratulations, that's a unit test. I wouldn't expect you to try and test that at an Integration or Acceptance level, because it'll be hidden behind so many other layers of code which could obscure your target or implement their own sanitisation, which nullifies the test. I'd also like it tested, because every page is using it. I've found the argument against unit testing usually comes from one of: - You think you have to unit test everything - You're on a time constraint - Learning is hard I really don't believe you need to unit test everything. In my mind it's only for complex or heavily reused code. These are two things where a simple code change can result in a big difference with very wide reaching consequences. That said, testing does tightly couple your code to those tests, which makes evolution and rapid development difficult to say the least.. but at least if you're writing a handful of tests for core code you will get into the habit of writing actually testable, SOLID code. Without it, people gravitate towards write horse poo poo, and I hate wading through it. Fake edit: PHP7 brings in scalar type hinting so can I run a heart monitor off it now?
|
|
#
?
Feb 18, 2016 05:10
|
|
|
v1nce posted:I started out with nothing, then PDO, then ADODB, then CakePHP's active record Models, and now I deal with Doctrine on a daily basis. I agree that porting a working application from Symfony to Laravel doesn't make a ton of sense. However, it is a classic case of a temporary fix for one problem ballooning into a full-fledged system and there were some bad design choices made early on that severely limit the performance of the project and make internal reporting way more difficult than it needs to be. As part of this project, I just finished up completely redesigning their database architecture, so if all of the entities and repositories need to be rewritten anyway, then porting it over to Laravel isn't as bad in this case, though it could easily backfire. I'll admit that I'm only a year or so removed from writing everything in straight SQL, so I enjoy all of the ORM talk and you guys are bringing up a lot of points that I hadn't even considered. Edit: I haven't finished going through the Laravel + Doctrine slides that I posted yet, but so far it seems to be filling in some of the gaps that other resources hadn't covered. Almost tempted to write something on this after I get it working. Aniki fucked around with this message at 08:00 on Feb 18, 2016 |
|
#
?
Feb 18, 2016 07:57
|
|
|
v1nce posted:I started out with nothing, then PDO, then ADODB, then CakePHP's active record Models, and now I deal with Doctrine on a daily basis. Well put. I think I need to look into Doctrine and figure out what's so great about it. Also I never have issue with raw queries or even partial raw queries against Eloquent models, so I'm not sure what's up with that. It sounds like Doctrine enforces separation of model and code better, which I find intriguing. As for unit testing/not testing, I learned how to do it at a place that was pretty strict about making sure its devs knew exactly how to unit test, how to mock everything, etc. They never got anything done. A year after I left the place I was still in touch with guys on the inside and all I would hear about is how they're on the same project they were on while I was still there. Meanwhile I've re-engineered my company's massive web application that went back to like 2004, added stacks of new features, modernized entire sections, wrote entire new apps and opened up whole new revenue streams for the company. We've had probably 2 production issues in the last year, neither of which would have been caught by unit testing (perhaps with JS unit tests). (and for a company that's not Google, an occasional bug in production is hardly a big deal. Also Google has production bugs all. the. time.) That said, I totally see the use case, shared components, APIs, billing methods, auth stuff. I just see a lot of developers jerking themselves off because their environment gives them warm fuzzies with how complicated it is, whereas my workflow is write code, commit, push to beta server, have stakeholders test, push to production, go home at 5.
|
|
#
?
Feb 18, 2016 13:51
|
|
|
Absolutely, as I said I see it was a trade-off; find that point between making it work and continue to work, and know when you're making it impossible to build upon. A lot of the time simple code doesn't need it. My own real world experience came from shortly after I had started doing testing. We had a testing super-star on the project who managed to get 100% coverage on all his library code, but he wasn't involved in the front-end development and final implementation. The day before a client milestone and demo we discovered that, despite all the tests, his implementation for some core objects wasn't suitable; the bug was the equivalent of product options only accepting a single option, not multiple. Because there were only 5 hours left in the day I said to the project manager "I can fix the code and make the demo work, but to hell with the tests." I was given a firm reprimand of "No, not to hell with all the tests. Everything must be tested". The result was avoiding modifying his code, a demo that only worked for the purposes of the specific demo, almost sleeping in the office, and the realisation I no longer wanted to work there. revmoo posted:That said, I totally see the use case, shared components, APIs, billing methods, auth stuff. I just see a lot of developers jerking themselves off because their environment gives them warm fuzzies with how complicated it is, whereas my workflow is write code, commit, push to beta server, have stakeholders test, push to production, go home at 5. If rapid development and the odd bug are OK (which most of the time they are) then this isn't a problem, and you can agile all the things. Tests only really appy for me on critical infrastructure and reuse. I do encourage people to Unit test their code if they think it's brittle or easily, quietly broken by changes. I think it was a Netflix talk where someone said (paraphrasing) they have a process-weak environment. If a process is good it'll stick, but if it's getting in the way then sensible people will ignore it, and they won't enforce it. Don't force smart people to do dumb things, because then you end up with dumb people (or the smart people leave).
|
|
#
?
Feb 19, 2016 03:45
|
|
|
revmoo posted:Programmers LOVE to over complicate and over-optimize the simplest things to the point of ridiculousness. I'd much rather start from a point of trying to do it correctly and then introduce incorrectnesses as needed. For example, start with a normalized database and introduce denormalization as needed. At my last job we decided to build a new system the "correct" way. The code was clean, clear, elegant, and well-tested. It was also a huge performance drag because we were doing one or two queries per entity and we needed a few thousand entities per page. We had to make the design "worse" in order to bring performance back under control (by introducing another layer of indirection in one specific area to get to the entities using a single query instead of a few thousand queries), but the whole design of the system was preserved elsewhere. Also, quoting this for truth: v1nce posted:Of all of these I prefer working with Doctrine, and my main reasoning is that the Entities and various other objects don't get polluted by the ORM once you're not using it. revmoo posted:Mind, I'm not saying testing is bad for PHP, but unit testing is a farce. Integration testing/regression testing is much more sensible and delivers a lot more value for the effort that it requires. Unit testing for an entire application is not time well spent, and you will get way better bang for your buck by testing entire processes, small chunks at a time. However, unit testing does have a place - in libraries and published, guaranteed APIs, where you actually do need detailed coverage to make sure you aren't gonna break someone else's code. Actual unit-level tests are also useful when filing bugs to ensure the bug does not return.
|
|
#
?
Feb 20, 2016 20:19
|
|
|
I"m using the framework, CAKEPHP. I work on a dev environment. When its good to go, my boss pushes the pages up to production. Sometimes, I'll make a database change (add a column, change a field type), and with these db changes, I have to tell my boss what to add to the production database. Is there something I can use, or something php does, like a script, that will automatically update the db with my dev changes? My boss said to look into "migration", but i couldn't really find anything. It's a very small team, but I don't think we are using our environments as well as we should. I just want to make sure our "dev to production" can be an easier process. Any help is appreciated.
|
|
#
?
Mar 7, 2016 23:43
|
|
|
Doesn't really help as I'm not certain about cake but I know laravel has a migration function for databases which will do what you are describing. Looks pretty similiar: http://book.cakephp.org/3.0/en/migrations.html poxin fucked around with this message at 23:52 on Mar 7, 2016 |
|
#
?
Mar 7, 2016 23:47
|
|
|
|
| # ? May 16, 2024 11:19 |
|
|
stoops posted:I"m using the framework, CAKEPHP. I work on a dev environment. When its good to go, my boss pushes the pages up to production. 100% look into https://phinx.org/. It is a great tool, and framework agnostic. Essentially, you track your database changes like you would any other code change. When you migrate your code to production, you can have a deploy script automatically run the migrations and Phinx will determine the new ones for you.
|
|
#
?
Mar 8, 2016 02:56
|
|